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Many  kinds  of  networked  devices  receive  and  execute  new  programs  from  various 
sources.  Since  we  may  not  fully  trust  the  producers  of  these  programs,  we  must  take 
measures  to  ensure  that  such  code  does  not  misbehave.  Currently  deployed  mobile  code 
formats  can  be  checked  for  memory  safety  and  other  security  properties,  but  they  are 
relatively  high-level.  A  type-presenting  compiler  generates  lower-level,  more  optimized 
code  that  is  still  verifiable.  This  increases  assurance  by  reducing  the  trusted  computing 
base;  we  need  not  trust  the  compiler  anymore.  Moreover,  lower-level  representations 
naturally  support  a  wider  variety  of  source  languages. 

Previous  research  on  type-preserving  compilation  focused  on  functional  languages 
or  safe  subsets  of  C.  How  to  adapt  this  technology  to  more  widely-used  object-oriented 
languages  was  unknown.  This  dissertation  explores  techniques  that  enable  a  single 
strongly-typed  intermediate  language  to  certify  programs  in  two  very  different  pro¬ 
gramming  languages:  Java  and  ML. 

The  major  contribution  is  an  efficient  new  encoding  of  object-oriented  constructs 
into  a  typed  intermediate  language.  I  give  a  complete  formal  translation  of  a  Java-like 
source  calculus  into  a  typed  lambda  calculus.  I  prove  that  both  languages  are  sound 
and  decidable,  and  that  the  translation  preserves  types. 

I  also  address  many  practical  concerns,  moving  beyond  the  formal  model  to  include 
most  features  of  the  Java  language.  To  stage  the  translation,  I  developed  lambda  JVM, 
a  novel  representation  of  Java  bytecode  that  is  simpler  to  verify.  I  describe  a  prototype 
compiler  that  supports  both  Java  and  ML,  sharing  the  same  typed  intermediate  language, 
optimizers,  code  generator,  and  runtime  system. 
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Chapter  1 


Compiler  Support  for  Safe  Systems 


Thesis:  A  strongly-typed  compiler  intermediate  language  can  safely  and  efficiently  ac¬ 
commodate  very  different  programming  languages.  To  underscore  the  significance  of 
this  statement,  I  will  broaden  my  focus  for  a  few  pages  to  explain  the  motivation  for 
work  on  type-preserving  compilers. 

We  are  entering  a  world  where  many  kinds  of  networked  devices  receive  and  execute 
new  programs  from  various  sources.  A  handheld  organizer  (or  even  a  cellular  phone) 
loads  code  from  a  PC  conduit,  from  an  infrared  link  with  another  device,  or  from  a 
wireless  network.  I  can  donate  the  idle  time  on  my  personal  computer  to  a  growing 
number  of  projects  that  use  widely  distributed  computation  to  crack  cryptographic 
protocols^  model  protein  foldingj^or  search  for  space  aliens^  Scientists  upload  new 
programs  to  satellites  or  space  exploration  devices.  My  web  browser  downloads  and 
runs  Java™  applets  to  provide  specialized  user  interfaces. 

In  all  of  these  applications,  we  may  not  fully  trust  the  producers  of  the  programs  we 
receive  and  run.  We  must  therefore  take  measures  to  ensure  their  code  does  not  mis¬ 
behave,  either  intentionally  or  accidentally.  Foreign  code  should  not  crash  or  hang  the 

Jhttp ://www. di stri buted . net/rc5/ 

2  http : //to  I di ng . stantord . edu/ 
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device,  exhaust  precious  resources,  or  interfere  with  other  programs  or  data.  Imagine 
‘SETI  @home’  uploading  a  portion  of  my  email  archive  each  time  it  exchanges  data  with 
its  server,  or  a  pointer  error  in  a  scientist’s  program  causing  the  computer  on  the  Mars 
Explorer  to  freeze.  In  space,  no  one  can  press  reset. 

These  examples  are  about  preventing  programs  from  doing  bad  things.  Ideally,  we 
might  also  want  to  ensure  that  programs  we  run  do  the  right  thing— that  they  compute 
what  we  intend.  Verifying  the  correctness  of  some  small  procedures  is  possible,  but 
the  technique  does  not  scale  to  realistic  programs.  We  do  not  usually  know  what  we 
intend  for  a  program  to  compute.  Indeed,  I  sometimes  run  programs  just  to  discover 
what  they  do!  Even  when  our  intentions  are  clear,  specifying  them  formally  is  difficult 
and  prone  to  error— just  like  programming.  For  these  reasons,  I  focus  just  on  safety, 
and  ignore  correctness. 

1.1  Safety  mechanisms 

Currently  deployed  tools  that  attempt  to  address  the  safety  of  foreign  code  include  dig¬ 
ital  signatures  and  reference  monitors.  A  digital  signature  identifies  and  authenticates 
the  sender  of  a  message  using  public-key  cryptography.  Perhaps  you  have  seen  a  dia¬ 
log  similar  to  the  one  in  figure  [TT]  on  the  facing  page.  In  this  case,  Microsoft  digitally 
signed  the  code  for  their  Internet  Explorer  Service  Pack.  The  dialog  assures  me  (the  user) 
that  the  code  I  am  about  to  install  did  indeed  come  from  Microsoft,  and  not  from  some 
unknown  third  party.  (Although  I  should  perhaps  be  suspicious  that  the  signature’s 
authenticity  is  verified  by  the  Microsoft  certification  authority.) 

Digital  signatures  can  enforce  trust  relationships  between  real-world  entities,  but 
they  do  not  directly  address  safety.  I  must  still  trust  Microsoft’s  assertion  that  the 
code  is  safe.  In  effect,  digital  signatures  ensure  only  that  I  know  who  to  blame  when 
something  goes  wrong;  this  is  why  the  next  dialog  is  typically  a  license  agreement! 
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Security  Warning 

Do  you  want  to  Install  and  run  nlernet  Explorer 
Service  Pack  2"  Signed  on  1/24, '02  3:14  PM  and 
distributed  by: 

Microsoft  Corporation 

Publisher  authenticity  verified  by 
Microsoft  Code  Signing  PC  A. 

■Caution:  Microsoft  Corporation  atieris  that  this 
content  is  safe.  You  should  only  install /view 
this  content  if  you  trust  Microsoft  Corporation 
to  make  that  assertion. 

Always  trust  content  from  Microsoft  Corporation 

f  No  ^  f  Yes  > 

_ A 


Figure  1.1:  Do  you  trust  Microsoft? 


Another  general  tool  is  a  reference  monitor.  Untrusted  code  is  confined  to  a  sand 
box,  wherein  it  can  do  whatever  it  pleases.  The  boundaries  of  the  sand  box  are  enforced 
by  the  monitor— it  can  deny,  regulate,  or  mediate  untrusted  code’s  access  to  the  out¬ 
side  world.  On  modern  workstations,  the  memory  management  hardware  supports  the 
operating  system’s  reference  monitor.  A  typical  OS  distinguishes  between  a  privileged 
kernel  mode  and  an  untrusted  user  mode.  User  programs  run  in  a  sand  box,  and  must 
perform  a  context  switch  into  the  kernel  to  access  the  machine’s  resources. 

Because  context  switches  are  relatively  expensive  (compared  to  a  normal  function 
call),  reference  monitors  typically  implement  fairly  coarse-grained  controls.  Using  the 
technology  to,  for  example,  enforce  encapsulation  or  access  control  between  the  mod- 
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ules  within  one  program  would  probably  be  overkill.  Moreover,  some  very  small  devices 
(watches  or  cellular  phones,  for  example)  may  not  have  the  requisite  hardware  support. 
Implementing  a  reference  monitor  via  software  rewriting  is  possible,  but  this  yields  even 
higher  overhead  since  dynamic  checks  must  guard  every  load  and  store. 

In  recent  years,  programming  language  support  for  safe  systems  is  finally  drawing 
much-deserved  attention.  Army  bounds  checking,  for  example,  ensures  that  programs 
do  not  (accidentally  or  intentionally)  use  an  array  pointer  to  access  arbitrary  memory. 
Similarly,  garbage  collection  eliminates  a  large  class  of  unsafe  memory  management 
errors.  Languages  that  enforce  encapsulation  ensure  that  a  rogue  module  cannot  ar¬ 
bitrarily  corrupt  the  private  data  of  another.  Exceptions  encourage  safe  programming 
because  uncaught  exceptions  rise  immediately  to  the  top  level  and  kill  the  program.  The 
default  behavior,  in  other  words,  is  to  stop  on  failure.  In  a  language  without  exceptions, 
the  default  behavior  is  usually  to  ignore  the  error  code  and  continue  merrily  onward. 

The  most  fundamental  language  feature  for  ensuring  safety  is  a  strong  type  system. 
I  must  assure  readers  accustomed  only  to  the  C  language  that  there  is  much  more  to 
modern  type  systems  than  distinguishing  between  int  and  float.  A  type  system,  just 
like  a  formal  logic,  can  encode  complex  properties  that,  for  example,  enforce  abstract 


data  types  or  access  control.  [Wallach,  Appel,  and  Felten  (2000)  showed  that  the  Java 
stack  inspection  mechanism— used  upon  accessing  a  privileged  resource  to  ensure  the 
proper  chain  of  authorization— could  be  formulated  within  a  type  system. 

The  term  type  safety  refers  to  a  collection  of  basic  properties  that  are  somewhat 
stronger  than  the  memory  safety  implemented  by  memory  management  hardware.  Type 
safety  precludes  segmentation  faults  and  stack  trashing,  but  also  ensures  that  program 
modules  respect  their  interfaces.  Critically,  a  type-safe  program  cannot  corrupt  its 
underlying  runtime  system.  A  type  system  is  sound  if  static  checking  admits  type-safe 
programs  only. 

Type  safety  is  not  just  necessary  for  a  secure  system,  but  already  represents  sig- 
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Date 

System 

1/24/02 

AOL  ICQ 

1/14/02 

Solaris  CDE 

12/20/01 

MS  u-PNP 

12/12/01 

SysV  ‘login’ 

11/29/01 

WUftpd 

11/21/01 

HP-UX  lpd 

10/25/01 

Oracle  9i  AS 

10/05/01 

CDE  ToolTalk 

Vulnerability 

remotely  exploitable  buffer  overflow 
buffer  overflow  vulnerability 
buffer  overflow  vulnerability 
remotely  exploitable  buffer  overflow 
format  string  vulnerability; 
free()  on  unallocated  pointer 
remotely  exploitable  buffer  overflow 
remotely  exploitable  buffer  overflow 
format  string  vulnerability 


Figure  1.2:  Recent  CERT  advisories 


nificant  progress  from  the  status  quo.  Figure  |1.2|  shows  a  sample  of  recent  security 
advisories  from  the  Computer  Emergency  Response  Team  (CERT).  A  great  many  of  the 
reported  vulnerabilities  are  buffer  overflows,  memory  management  problems,  or  for¬ 
mat  string  bugs  (referring  to  C’s  unsafe  printf  routine).  All  such  vulnerabilities  could 
be  prevented  by  using  type-safe  languages. 


1.2  Type-preserving  compilers 


To  ensure  safe  execution  of  untrusted  code,  is  it  sufficient,  then,  to  program  in  type- 
safe  languages?  Although  such  a  revolution  would  enormously  improve  the  status  quo, 
I  must  answer  no.  First,  companies  like  Microsoft  are  unlikely  to  ship  the  source  code 
for  users  to  type-check  and  compile.  Even  if  vendors  distribute  something  close  enough 
to  source  code  that  type  safety  can  still  be  verified— Java  bytecode,  for  example— we 
must  still  trust  the  compiler.  As  a  large  and  complicated  program,  a  compiler  can  con¬ 
tain  serious  bugs— or  even  Trojan  horses  (Thompson  1984)— that  compromise  safety. 
Handing  carefully  type-checked  code  to  an  untrusted  compiler  is  still  a  serious  risk. 

The  “orange  book”  (Department  of  Defense  19851  identifies  the  trusted  computing 
base  (TCB)  as  the  elements  of  a  system  responsible  for  supporting  the  security  policy. 
Identifying  and  minimizing  code  in  the  TCB  increases  assurance  in  the  entire  system. 
Even  when  using  a  type-safe  programming  language,  the  compiler  is  part  of  the  TCB. 
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An  exciting  new  line  of  research  aims  to  enable  higher  assurance  systems  with  a 
minimal  TCB  (Appel  2001).  Raw  machine  code,  annotated  with  the  right  types  and 
invariants,  can  be  verified  as  type-safe  by  an  extremely  small  verifier.  Even  the  type 
system  for  the  machine  code  can  be  proved  sound  in  some  machine-checkable  logic. 

An  essential  component  of  this  system  is  a  type-preserving  or  certifying  compiler. 
Rather  than  discard  the  source  language  types,  such  a  compiler  transforms  them  along 
with  the  program  into  a  strongly-typed  intermediate  language,  and  finally  into  a  typed 
assembly  language.  Such  a  compiler  need  not  be  trusted  since,  along  with  the  object 
code,  it  generates  evidence  that  the  code  is  safe.  Type  preservation  is  challenging, 
both  in  theory  and  in  practice.  Lower-level  code  always  needs  more  sophisticated  types 
to  justify  its  safety.  Unfortunately,  such  type  systems  are  difficult  to  implement,  and 
can— if  we  are  not  vigilant— hinder  efficient  execution. 

Until  now,  research  in  this  area  has  concentrated  on  compiling  either  functional 
languages  or  a  safe  subset  of  C.  Tarditi  et  al.  (1996)  introduced  TIL,  a  compiler  for 
the  polymorphically-typed  functional  language  Standard  ML  (Milner  et  al.  1997).  Shao 


(1997)  implemented  LLINT,  a  typed  intermediate  language  for  the  Standard  ML  of  New 


Jersey  compiler  (|Appel  and  MacQueen  1991).  |Necula  and  Lee  (1998  )  pioneered  the  idea 
of  proof-carrying  code  and  built  a  certifying  compiler  for  a  safe  subset  of  C.  finally, 
Morrisett  et  al.  (1999a!  created  two  distinct  type-preserving  compilers:  one  for  Popcorn, 


a  safe  C-like  language,  and  another  (written  in  Popcorn)  for  a  subset  of  Scheme  (Clinger 
and  Rees _199l},  the  dynamically- typed  functional  language. 


If  this  technology  is  to  succeed  in  the  real  world,  certifying  compilers  must  support 
real-world  programming  languages  and  development  models. 
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1 . 3  Contributions 


This  work  shows  that,  with  carefully  designed  encodings,  a  single  typed  intermediate 
language  can  safely  and  efficiently  accommodate  not  only  a  typical  functional  language 
(Standard  ML)  but  a  typical  object-oriented  language  (Java)  as  well. 

Specifically,  we  developed  a  formal  translation  of  Featherweight  Java  (Igaraslif  Pierce 
and  Wadler  200i  I  into  a  typed  A-calculus.  At  run  time,  method  calls  have  precisely  the 
same  operational  behavior  as  a  standard  untyped  implementation.  Classes  inherit  and 
override  methods  from  super  classes  with  no  overhead.  We  support  mutually  recursive 
classes  while  maintaining  separate  compilation.  Dynamic  casts  are  implemented  as 
polymorphic  methods  using  tags  generated  at  link-time.  The  target  of  this  translation 
(Mini  JFlint)  is  sound  and  decidable,  but  really  quite  conventional— rooted  in  decades 
of  type  theory  research.  It  is  a  minor  extension  of  the  kind  of  calculus  typically  used  to 
represent  functional  languages  in  compilers  (|Peyton  Jones  et  al.  1992|  |Shao  and~Appel 
1995;  Morrisett  et  al.  1996). 

This  work  includes  a  formal  proof  that  well-formed  Featherweight  Java  programs 
map  to  well-formed  Mini  JFlint  programs.  Since  we  also  proved  that  Mini  JFlint  is  sound, 
translated  programs  do  not  become  stuck  at  run  time. 

We  supplement  these  significant  theoretical  results  with  work  to  address  practical 
concerns.  We  developed  informal  extensions  to  support  many  Java  features  that  are  not 
included  in  Featherweight:  interfaces,  constructors,  super  calls,  privacy,  and  exceptions, 


for  example.  Our  prototype  compiler  is  based  on  Standard  ML  of  New  Jersey  (Appel  and 


MacQueen  1991).  It  reads  Java  class  files  (bytecode  for  the  Java  virtual  machine)  and 
compiles  them  to  low  level  JFlint  code,  with  type  information  preserved.  To  stage  the 
translation  from  class  files  to  JFlint,  we  designed  AJVM,  a  novel  representation  of  Java 
bytecode  that  is  more  explicit  and  simpler  to  verify.  After  JFlint,  the  compiler  calls 
MLRISC  (George  1997)  to  generate  machine  code  for  a  variety  of  architectures. 
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The  ML  and  Java  front  ends  share  optimizations  and  back  ends.  Programs  from 
either  language  run  together  in  the  same  interactive  runtime  system  with  the  same 
garbage  collector.  The  design  of  JFlint  itself  supports  a  pleasing  synergy  between  the 
encodings  of  Java  and  ML.  JFlint  does  not,  for  example,  treat  Java  classes  or  ML  modules 
as  primitives.  Rather,  it  provides  a  low-level  abstract  machine  model  and  sophisticated 
types  that  are  general  enough  to  prove  the  safety  of  a  variety  of  implementations. 


1.4  Structure  of  this  dissertation 


This  chapter  sketched  the  motivation  for  the  work  and  outlined  our  contributions.  The 
next  chapter  reviews  the  idea  of  object  encoding,  explaining  why  type-safe  encodings  are 
so  important  and  challenging.  Chapters  3  through  5  are  the  core  theory,  expanded  from 


our  journal  article,  “Type-Preserving  Compilation  of  Featherweight  Java”  (|League,  Shao,| 
and  Trifonov  2002bl.  We  formulate  models  of  the  source  and  intermediate  languages, 
give  a  formal  translation  between  them,  and  prove  several  important  properties. 

The  remaining  chapters  supplement  the  theory  with  discussions  of  various  practical 
issues.  Chapter  6  addresses  some  of  the  Java  features  that  are  not  covered  in  the  formal 
presentation.  Chapter  7  is  an  expansion  of  a  paper  called  “Functional  Java  Bytecode” 

( League, JTifonov^and  Shao  2001a!  describing  the  AJVM  intermediate  language  and  the 
niche  it  was  designed  to  occupy.  Chapter  8  summarizes  the  implementation  of  the 
prototype  compiler.  Finally,  chapter  9  concludes  with  some  exciting  ideas  for  future 
research. 

Comparisons  to  previous  work  are  made  throughout  the  dissertation.  Other  object 


encodings  are  discussed  in  sections  2.3  and  5.9  Alternative  representations  of  Java 


bytecode  are  mentioned  in|7.5|  Certified  implementations  of  object-oriented  languages 
are  covered  in  sections  [2751  and  liL2l 


Chapter  2 


Object  Encoding 


Booch  (1994  page  38)  gives  the  following 


[It]  is  a  method  of  implementation  in  which  programs  are  organized  as  coop¬ 
erative  collections  of  objects,  each  of  which  represents  an  instance  of  some 
class,  and  whose  classes  are  all  members  of  a  hierarchy  of  classes  united  via 
inheritance  relationships. 


His  book  describes  techniques  for  analyzing  requirements  and  designing  software  using 
classes  of  objects  as  the  unifying  model. 

I  do  not  make  any  particular  claims  about  the  merits  of  object-oriented  program¬ 
ming,  analysis,  or  design.  It  is  clear,  however,  that  objects  represent  a  different  way 
of  structuring  software,  as  compared  to  functional  or  procedural  programming.  Fur¬ 
thermore,  there  is  no  denying  that  object-oriented  technology  remains  popular,  from 
the  new  safe  languages  Java  (|Gosling  et  al.  20001  and  C#  ^Liberty  2002}  to  scripting  lan¬ 
guages  Python  (|Lutz  200T)  and  Ruby  (Thomas  and  Hunt  2000}  to  that  old  standby,  C++ 
(Stroustrup _1997 1.  Therefore,  for  certifying  compiler  technology  to  be  viable,  we  must 
find  an  efficient  way  to  support  object-oriented  programming  languages. 

This  chapter  is  about  the  art  and  science  of  object  encoding— representing  object- 
oriented  features  in  languages  (or  models  of  computation)  that  lack  them.  I  will  keep 
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the  formal  semantics  and  type  theory  to  a  minimum  (there  is  plenty  of  space  for  that 
in  subsequent  chapters),  so  that  any  student  of  computer  science  can  appreciate  the 
significance  of  this  work. 


2.1  Why  we  need  encodings 


The  von  Neumann  architecture— the  model  on  which  virtually  all  electronic  computers 
are  based— has  no  notion  of  methods,  objects,  classes,  or  inheritance.  To  implement 
these  features,  we  must  express  them  using  simple  instructions  that  load  and  store 
words  in  a  sequential  memory.  This  is  not  surprising;  such  is  the  job  of  a  compiler  for 
any  high-level  programming  language.  Object-oriented  features  seem  particularly  high- 
level  because  they  naturally  decompose  into  operations  on  records  and  functions— the 
abstractions  of  procedural  languages. 

Consider  the  operation  to  invoke  some  method  of  an  object.  The  definition  that 
opened  this  chapter  emphasized  classes  and  inheritance,  but  one  other  feature  is  widely 
considered  essential  for  object-oriented  programming:  dynamic  (or  late)  binding  of 


methods.  Booch  (1994  page  116)  distinguishes  it  this  way: 


Inheritance  without  polymorphism  is  possible,  but  it  is  certainly  not  very 
useful.  This  is  the  situation  in  Ada,  in  which  one  can  declare  derived  types, 
but  because  the  language  is  monomorphic,  the  actual  operation  being  called 
is  always  known  at  the  time  of  compilation. 


With  dynamic  binding,  the  operation  is  not  known  at  compile  time.  Rather,  the  intuition 
is  that  we  send  a  message  to  the  object  to  request  some  operation,  but  the  object  itself 
chooses  (usually  by  virtue  of  the  class  that  created  it)  which  method  gets  invoked. 

Normally,  the  object  includes  some  data  structure  for  mapping  messages  to  function 
pointers.  In  the  case  of  single  inheritance  class-based  languages  (such  as  Java  and  C#), 
this  data  structure  is  just  a  simple  record,  traditionally  called  the  virtual  function  table, 
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public  static  void  example  (Object  x,  Object  y) 
{  x.toStringO 

//virtual  method  call  expands  to: 

if  (x  ==  null)  throw  NullPointerException; 

r\  =  x.vtbl; 

Y2  =  ri.toString; 

call  T2(x ); 

} 


Figure  2.1:  Expanding  method  invocation  to  low-level  code 


or  vtable  for  short.  The  typical  syntax  (after  C++)  even  suggests  that  method  invocation 
is  some  combination  a  record  access  and  a  function  call:  obj.meth  (args). 

Indeed,  methods  are  just  standard  functions  with  an  implicit  self  parameter  (called 
th  is  in  Java)  referring  to  the  current  object.  All  instances  of  the  same  class  share  the 
same  vtable.  Subclasses  append  new  methods  and  fields  to  the  vtable  and  object  layout, 
but  do  not  rearrange  the  members  of  super  classes.  This  way,  we  always  know  where 
to  find  a  field  in  an  object,  even  if  the  object  was  created  by  some  unknown  subclass. 

To  invoke  a  virtual  method,  we  simply  load  the  vtable  pointer  from  the  object,  load 
the  function  pointer  from  the  vtable,  and  then  call  the  function,  providing  the  object 


itself  as  the  now-explicit  self  argument.  Figure  |2.1|  shows  Java  method  invocation  ex¬ 
panded  into  lower-level  code.  The  identifiers  Y\  and  Y2  denote  registers. 


2.2  Encodings  must  enforce  safety 

A  certifying  compiler  must  justify  that  the  indirect  call  to  Y2  is  safe;  this  is  not  at  all 
obvious.  If  x  is  an  instance  of  a  subclass  of  Object,  then  the  method  in  Y2  might  require 
of  x  additional  fields  and  methods  that  are  unknown  to  the  caller.  Self-application 
works  thanks  to  a  rather  subtle  invariant.  One  way  to  upset  that  invariant  is  to  select  a 
method  from  one  object  and  pass  it  another  object  as  the  self  argument.  For  example, 
replace  just  the  last  instruction  above  with  call  r2(y). 
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class  Ref  extends  Object 
{  public  byte[]  vec; 

public  String  toString  ( ) 

{  vec[  1  3]  =  42; 
return  "Ha  ha!"; 

} 

} 

class  Int  extends  Object 
{  public  int  n; 

} 

public  static  void  deviant  (Object  x,  Object  y) 

{  //  as  low-level  code 

if  (x  ==  null)  throw  NullPointerException; 
r\  =  x.vtbl;  //fetch  method  from  x 
T2  =  r\  .toString; 

call  r2(y)',  //  pass  y  as  self  argument 

} 

deviant  (new  Ref  (...),  new  Int  (...)); 

Figure  2.2:  Using  an  arbitrary  integer  as  a  pointer 


This  might  seem  harmless;  after  all,  both  x  and  y  are  instances  of  Object.  It  is  un¬ 
sound,  however,  and  any  unsoundness  can  be  exploited.  Figure \Z2\ contains  a  complete 
example  that  exploits  such  code  to  use  an  arbitrary  integer  as  the  address  of  a  byte 
vector.  Once  we  can  do  that,  all  bets  are  off. 

Class  Ref  extends  Object  with  a  byte  vector  and  overrides  toString  to  write  to  the 
byte  vector  before  returning  an  innocuous  string.  Class  Int  extends  Object  with  just  one 
integer  field.  Importantly,  in  the  representations  of  Ref  and  Int  objects,  the  byte  vector 
and  the  integer  occupy  the  same  slot. 

The  deviant  method  uses  low-level  code  to  fetch  the  toString  method  from  x,  and 
pass  it  y  as  the  self  argument  this.  Finally,  the  main  program  calls  deviant  with  some 
Ref  object  as  x  and  some  Int  as  y.  What  happens?  The  call  in  deviant  will  jump  to 
Ref.toString  with  this  bound  to  the  Int  object.  That  method  attempts  to  write  to  the 
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byte  vector,  but  finds  an  integer  there  instead.  This  is  not  type  safe! 

Of  course,  it  is  unlikely  that  a  legitimate  compiler  would  ever  generate  such  code— 
but  that  is  no  consolation.  Remember,  we  do  not  trust  the  producer;  perhaps  he  is 
writing  malicious  code  in  assembly  language.  If  so,  we  must  detect  it. 


2.3  Classic  encodings 


How  can  a  type  system  ensure  that  low-level  operations  properly  encode  objects,  so 
that  erroneous  or  malicious  code  is  detected?  There  is  significant  precedent  for  mod¬ 
eling  objects  in  typed  A-calculi  (Barendregt  1992).  Bruce,  Cardelli,  and  Pierce  (1999) 
summarize  several  such  results  in  a  uniform  framework. 

We  briefly  demonstrate  how  one  of  these  encodings  properly  rejects  the  code  in 


figure  2.2  Pierce  and  Turner  (1994)  represent  objects  in  F ^  (a  higher-order  typed  A- 


calculus  with  subtyping)  using  an  existential  type  to  hide  the  private  representations  of 
objects.  That  is,  instances  of  class  Object  have  type 


35::Type.  {state  :s,  vtbl :  {toString  :s^String}} 

where  s  is  a  type  variable  that  masks  the  types  of  fields.  The  underlying  representation 
is  a  pair  containing  the  values  of  the  fields  (i.e.,  the  state  of  the  object)  and  the  method 
table  (vtbl).  Each  method  expects  to  receive  the  object  state  (not  the  whole  object)  as  its 
first  argument. 

The  method  invocation  sequence  for  this  encoding  starts  with  an  open  instruction 
to  eliminate  the  existential  type: 


(si,n)  =  open  x; 

r2  =  r\  .vtbl.  toString; 
call  r2(r±.  state); 
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The  open  introduces  a  fresh  type  variable  S\  to  represent  the  abstract  type  locally.  Then, 
r2  gets  afunction  of  type  5i  — String,  andn. state  is  avalue  of  type  si,  so  the  call  is  safe. 
What  happens  if,  as  in  figure  [272]  we  try  to  pass  y' s  state  to  x’s  method?  First,  we  must 
open  y,  yielding  a  record  r3  and  a  fresh  type  variable  52. 


<5i,ri>  =  open  x; 

<52, r3)  =  open  y; 

T2  =  ri.vtbl.toString; 

call  r2(r3. state);  // type  error 


Since  r3. state  has  type  52,  attempting  to  pass  it  to  Y2  is  a  type  error. 

These  object  encodings  detect  low-level  errors  by  embedding  objects,  classes,  and 
methods  in  foundational  calculi  that  are  known  to  be  sound.  They  are  successful  models 
of  these  features,  and  helpful  for  comparing  the  expressive  power  of  object  calculi  with 
A-calculi.  They  are  not,  unfortunately,  directly  applicable  for  compiling  modern  object- 
oriented  languages.  First,  in  the  early  object  models  (Abadi  and  Cardelli  1996)  classes 
and  method  overriding  were  afterthoughts,  not  essential  features  as  in  Java.  |Fisher  and| 
Mitchell  (1998)  made  the  relationship  clear  by  modeling  classes  as  extensible  objects, 


but  that  does  not  bring  us  any  closer  to  a  von  Neumann  machine. 

Second,  the  classic  encodings  have  various  inefficiencies,  making  them  unsuitable 


for  use  in  compilation.  For  example,  the  aforementioned  existential  encoding  of  Pierce 


and  Turner  (19941  seems  reasonably  efficient  until  we  examine  inheritance  (section  6  in 


their  paper).  To  permit  subclasses  to  extend  the  object  representation,  they  introduce 
function  arguments  get  and  put  to  coerce  between  the  final  representation  and  the 
current  representation  at  some  level  in  the  class  hierarchy.  Methods  must  call  these 
coercion  functions  before  reading  or  writing  the  internal  representation.  Moreover,  the 
coercions  grow  with  the  depth  of  the  hierarchy.  Compiler  analyses  may  alleviate  some 
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of  the  penalty,  but  removing  the  coercions  entirely  would  require  analyzing  the  whole 
program  or  duplicating  the  inherited  code  in  each  subclass. 

The  recursive  bounded  existential  of  Abadi,  Cardelli,  and  Viswanathan  (1996)  has 
a  superfluous  self  pointer  to  dereference  on  method  invocation.  The  simpler  recursive 
record  encodings  are  not  suitable  for  Java:  Cardelli  (1988)  does  not  handle  dynamic 


binding;  Fisher,  Honsell,  and  Mitchell  (1994)  support  dynamic  binding,  but  selecting  a 


method  and  substituting  the  self  argument  remains  an  atomic  operation. 


2.4  Efficient  encoding 

The  fundamental  contribution  of  our  work  is  a  simple,  efficient  encoding  that  is  suitable 
for  compilation  of  modern  object-oriented  languages  such  as  Java.  Unlike  recursive 


record  encodings,  it  supports  dynamic  binding  with  low-level  primitives.  Unlike  Abadi, 


Cardelli,  and  Viswanathan  (1996},  it  needs  no  extra  pointers.  Unlike  Pierce  and  Turner 
(1994},  methods  can  be  reused  in  subclasses  with  no  overhead.  Moreover,  the  ambient 
type  theory  is  quite  simple;  we  do  not  need  subtypes  or  bounded  quantification. 

The  classic  encodings  all  assumed  that  subsumption  was  necessary.  This  is  what 
allows  an  instance  of  a  subclass  (Hexagon)  to  be  substituted  wherever  a  super  class 
(Shape)  is  expected.  This  is  certainly  a  desirable  (and  nearly  universal)  property  in 
object-oriented  languages  at  the  source  level.  For  a  compiler  intermediate  language,  it 
is  acceptable  to  require  explicit  upward  casts  instead,  as  long  as  they  cost  nothing  at 
runtime.  Type  manipulations  (such  as  the  open  in  previous  examples)  guide  the  type 
checker,  but  are  erased  before  the  code  is  run.  Therefore,  the  implicit  subsumption 
in  previous  models  can  be  replaced  with  explicit  type  manipulations.  The  details  and 
proofs  about  our  encoding  will  be  explained  in  the  next  three  chapters. 

Concurrently  with  our  work,  two  other  researchers  developed  encodings  that  seem 
to  have  similar  properties.  Glew  (2000a)  translates  a  class-based  object  calculus  using  a 
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special  kind  of  existential  quantifier.  Crary  (19991  encodes  the  object  calculus  of|Abadi 
and  Cardelli  (19961  using  an  existential  and  an  intersection  type: 


3«::Type.  «  a  { vtbl :  {toString :  a^String}, . . . } 

In  words,  an  object  is  both  abstract  (having  type  a)  and  a  record  containing  a  vtable 
whose  methods  expect  a  self  argument  of  type  a.  Chapter  [5]  ends  with  a  detailed  com¬ 
parison  of  these  three  efficient  encodings. 


2.5  Another  approach 

Rather  than  encode  object-oriented  features  in  a  lower-level  type-safe  language,  some 
systems  try  to  guarantee  safety  using  the  abstractions  of  the  source  language  directly. 
Two  years  ago,  Colby  et  al.  (2000)  of  Cedilla  Systems  presented  initial  results  about 
Special  J,  a  certifying  compiler  for  Java.  They  described  the  design,  defined  some  of 
the  predicates  used  in  verification  conditions,  explained  their  approach  to  exceptional 
control  flow,  and  gave  some  experimental  results.  Their  running  example  included  a 
loop,  an  array  field,  and  an  exception  handler. 

The  Special  J  system  uses  predicate  constructors  to  express  proof  obligations  and 
properties  about  the  object  layout  and  class  hierarchy.  For  reference,  we  reprint  some 
of  the  key  constructors  from  Colby  et  al.  (2000)  in  figure  [273]  on  the  facing  page.  As  a 
simple  demonstration,  consider  the  rules  to  determine  whether  a  field  access  is  safe. 
From  the  source  program,  we  would  derive  (ifield  COT )  for  some  class  C,  offset  O,  and 
type  T.  Suppose  then  that  (type  E  (jinstof  C))  for  some  E.  With  these  and  (nonnull  E) 
as  pre-conditions,  a  particular  rule  in  the  system  derives  (type  (add  E  O )  (ptr  T)).  In 
words,  adding  offset  O  to  the  object  reference  yields  a  pointer  to  a  field  of  type  T.  Next, 
using  the  axiom  (size  (ptr  _)  4),  another  rule  concludes  (saferd4  (add  E  O ) ) . 
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constructor 
jint,  jfloat,  ... 
(jinstof  C) 

(jvtbl  C) 

(jimplof  C  S ) 

(ptr  T) 

(add  E  O ) 

(size  T  B) 

(type  E  T ) 
(jextends  C  D) 
(vmethod  COS ) 
(ifield  COT) 
(nonnull  £) 
(saferd4  £) 


meaning 

Java  primitive  types 

the  type  of  an  instance  of  class  C  (or  some  subclass) 
type  of  the  virtual  function  table  of  class  C 
type  of  a  method  from  class  C  with  signature  S 
type  of  a  pointer  to  a  value  of  type  T 
denotes  the  addition  of  offset  O  to  address  E 
a  value  of  type  T  occupies  B  bytes 
E  denotes  a  value  of  type  T 
encodes  the  subclass  relationship 

class  C’s  vtable  contains  a  method  with  signature  S  at  offset  O 
instances  of  class  C  have  a  field  of  type  T  at  offset  O 
E  is  not  null 

it  is  safe  to  read  four  bytes  beginning  at  address  E. 


Figure  2.3:  Predicate  constructors  in  Special  J 


Due  to  limited  space,  Colby  et  al.  (2000)  did  not  address  virtual  method  calls  in  their 
paper.  We  contacted  the  authors  to  learn  the  details,  particularly  in  the  context  of  the 
malicious  code  we  gave  in  figure  [272]  on  page  [12]  From  the  signature  of  the  deviant 
method,  their  certifier  establish  the  argument  types: 


(type  x  (jinstof  Object))  (type  y  (jinstof  Object)) 


A  rule  in  the  system  permits  x  and  y  to  be  treated  also  as  read-only  pointers  to  the 
vtable  of  Object  (since  the  vtable  is  at  offset  zero).  After  the  assignment  to  r\. 


(type  r\  (jvtbl  Object)) 


From  the  class  definition,  we  know  the  offset  Ots  of  the  toString  method: 


(vmethod  Object  Ots  ‘( )String’) 


The  signature  ‘( )String’  means  that  the  method  takes  no  additional  arguments  and 
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returns  a  String.  After  the  assignment  to 


(type  r2  (jimplof  Object  ‘( )String’)) 


With  this  knowledge  of  the  type  of  r2,  the  certifier  determines  that  a  call  to  r 2  is  safe  as 
long  as  the  self  argument  has  type  (jinstof  Object).  Since  both  x  and  y  have  this  type, 
the  malicious  code  in  figure  [2T2| is  accepted.  pNfecula  (2001 1  confirmed  that  our  example 
exposed  an  unsoundness  in  the  inference  rules  of  Special  J.  The  validity  of  the  code 
certification  relies  critically  on  the  assumption  that  the  inference  rules  are  sound— they 
are  part  of  the  trusted  computing  base.  Colby  et  al.  (20001  did  not  prove  a  soundness 
theorem  for  their  system. 

Necula  (2001}  proposed  a  solution  where  the  predicates  jvtbl  and  jimplof  mention 


the  identity  of  the  object  from  which  they  came.  Then,  the  virtual  call  is  safe  only  if  the 
identity  of  the  self  argument  matches  that  of  the  jimplof  type.  It  is  interesting  to  relate 
this  strategy  to  the  object  encodings  discussed  earlier  in  this  chapter.  We  believe  it 
bears  some  resemblance  to  the  encoding  of  Crary  (19991.  Since  loading  the  virtual  table 
from  x  introduces  a  type  containing  the  identity  of  x,  it  is  as  if  we  implicitly  opened  a 
package  to  introduce  some  abstract  type.  The  usual  rules  still  permit  fetching  methods 
from  x  (whose  types  also  mention  x).  In  addition,  the  revised  rule  governing  the  call 
has  us  treat  x  as  a  value  of  the  new  abstract  type.  Similarly,  the  intersection  type  in 
Crary’s  encoding  permits  x  to  be  treated  both  as  abstract  and  as  a  table  of  methods 
(that  expect  x  as  the  self  argument). 

Of  course,  resemblance  to  a  foundational  encoding  does  not  imply  soundness.  A 
rigorous  soundness  proof  for  a  real  implementation  like  Special  J  is  extremely  difficult. 
A  more  reasonable  approach— the  one  we  take  in  this  dissertation— is  to  formulate  a 
model  and  prove  soundness  for  a  significant  subset  of  the  real  system.  Having  no  proof 
at  all  is  dangerous. 


2.5.  ANOTHER  APPROACH 
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We  expect  that  a  soundness  proof  for  Special  J— even  for  a  subset— will  be  complex, 
for  a  couple  of  reasons.  First,  the  Special  J  inference  rules  encode  much  of  the  semantics 
of  Java,  giving  meaning  to  features  like  inheritance  and  virtual  methods.  Therefore, 
the  soundness  of  Special  J  subsumes  the  soundness  of  Java  itself.  In  contrast,  the 
calculi  used  for  object  encoding— including  Mini  JFlint  from  chapter  [4]—  are  not  at  all 
Java-specific.  Their  soundness  proofs  are  completely  independent  of  the  soundness  of 
whatever  object-oriented  languages  they  support. 

Another  potential  difficulty  is  the  difference  in  granularity  between  the  predicate 
constructors  and  the  machine  instructions  they  describe.  Many  predicates  deal  with 
high-level  abstractions  such  as  classes  and  virtual  methods.  The  machine  model,  on  the 
other  hand,  deals  with  code  pointers  and  blocks  of  memory.  The  types  of  Mini  JFlint, 
in  contrast,  encode  the  requisite  invariants  with  precisely  the  granularity  at  which  the 
code  operates— that  of  functions  and  records. 


Chapter  3 


Source  Language:  Featherweight  Java 


Our  goal  is  a  type-preserving  compiler  that  supports  Java.  To  ensure  that  the  techniques 
we  use  in  this  effort  are  sound,  it  is  critical  to  study  them  in  the  context  of  a  formal 
system.  By  working  with  an  idealization  of  the  actual  compiler,  we  can  develop  precise 
semantics,  perspicuous  translations,  and  rigorous  proofs  of  important  properties.  A 
compiler  is  nothing  more  than  a  translator  from  some  source  language  into  some  target 
language.  We  must  therefore  formally  specify  these  two  languages;  such  is  the  aim  of 
this  and  the  next  chapter. 

The  most  important  property  we  want  to  prove  is  that  our  compiler  maps  well-typed 
programs  in  the  source  language  (Java)  to  well-typed  programs  in  the  target  language 
(JFlint).  To  prove  this,  we  need  a  formalization  of  Java  with  a  notion  of  well-typed 
programs.  Specifically,  we  need  a  calculus  with  a  type  system,  an  operational  semantics, 
and  a  soundness  proof. 

Concurrently  with  the  start  of  our  work  on  this  project,  many  researchers  worked 


on  provably  type-safe  idealizations  of  Java  (Drossopoulou  and  Eisenbach  1999  Syme 


1999|  [Qian  1999).  The  ClassicJava  language  by  Flatt,  Krishnamurthk  and  Felleisen 


(1999)  features  classes,  interfaces,  fields  with  shadowing,  dynamic  method  binding, 


abstract  methods,  object  creation,  casts,  and  local  variables.  Although  our  techniques 
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CL  ::=  class  C  extends  C'  {  Ci  f  1 ; . . .  CM  fn;  K  Mi . . .  Mm  } 

K  ::=  C  (Ci  fi  ...Cn  fn)  {  super(fi . . .  fjt);  this.ffe+i  =  ffc+i;  ■  ■  ■  this.fM  =  fn\  } 
M  ::=  C  m  (Ci  xi . . .  Cn  x„)  {  return  e;  } 
e  ::=  x  |  e.f  |  e.m  (ei,...,en)  I  new  C  (ei,...,en)  I  (C)  e 


Figure  3.1:  Abstract  syntax  of  Featherweight  Java 


support  all  those  features  (League,  Shao,  and  Trifonov  1999},  the  complex  semantics  of 
ClassicJava  caused  difficulty  in  proving  essential  properties  of  our  translation. 

Featherweight  Java  (FJ)  is  a  particularly  small  calculus  by  Igarashi,  Pierce,  and  Wadler 


(2001).  Its  semantics  and  soundness  proof  are  easy  to  understand,  yet  it  still  features 


classes,  inheritance,  immutable  fields,  dynamic  method  binding,  simple  object  creation, 
and  dynamic  casts.  Most  importantly,  with  FJ  we  can  demonstrate  the  major  techniques 
of  our  translation  in  a  reasonably  clean  and  comprehensible  manner.  The  rest  of  this 
chapter  formally  defines  FJ.  We  made  a  few  minor  adaptations  to  the  typing  rules;  oth¬ 


erwise,  the  presentation  follows  very  closely  that  of  Igarashi,  Pierce,  and  Wadler 


3.1  Syntax 

Figure  [rT]  contains  a  BNF  grammar  for  the  abstract  syntax  of  Featherweight  Java.  Key¬ 
words  are  marked  in  bold  face.  Class  declarations  (CL)  contain  the  names  of  the  new 
class  and  its  super  class,  a  sequence  of  field  declarations,  a  constructor  (K),  and  a  se¬ 
quence  of  method  declarations  (M).  We  use  letters  A  through  E  to  range  over  class  names, 
f  and  g  to  range  over  field  names,  m  over  method  names,  and  x  over  formal  parameter 
names.  There  are  five  forms  of  expressions:  variable  references,  field  selection,  method 
invocation,  object  creation,  and  cast.  A  program  ( CT,e )  consists  of  a  fixed  class  table 
(CT)  mapping  class  names  to  declarations,  and  a  main  program  expression  e. 

There  are  no  assignments,  interfaces,  super  calls,  exceptions,  or  access  control  in 
FJ.  Constructors  are  greatly  simplified:  there  can  be  only  one,  and  it  must  take  all  the 
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class  Pt  extends  Object 
{  int  x; 


Pt  ( 

int  x) 

{super ( 

);  this  .  x  =  x  ; 

} 

int 

getx  () 

{ return 

this . x  ;  } 

Pt 

move(int  dx) 

{ return 

new  Pt  ( this  .x 

+ 

dx  );  } 

Pt 

bump  ( ) 

{ return 

this  .  move  (1 ); 

} 

Pt 

} 

max  (Pt  p ) 

{ return 

this  .x  >  p.x? 

this  :  p  ; } 

class  SPt  extends  Pt 

{  int 

s ; 

SPt  ( 

int  x ,  int  s  ) 

{  super(x  );  this  .  s  =  s 

; } 

int 

gets  () 

{ return 

this . s  ;  } 

Pt 

move(int  dx) 

{ return 

new  SPt  ( this  . 

X 

+  this . s 

this  . 

s 

); } 

SPt 

zoom(int  s ) 

{ return 

new  SPt  ( this  . 

X 

,  this . s  * 

} 

Main  program: 

((  SPt  )  (  new  Pt  (2).  max(  new  SPt  (1 ,2).  bump  ( ) ))).  zoom(3).gets  ( ) 

Figure  3.2:  Sample  FJ  program  with  integers,  arithmetic,  and  conditional  expressions 


fields  as  arguments,  in  the  same  order  that  they  are  declared  in  the  class  hierarchy.  FJ 
permits  recursive  class  dependencies  with  the  full  generality  of  Java.  A  class  can  refer 
to  the  name  and  constructor  of  any  other  class,  including  its  sub-classes.  While  this 
does  not  complicate  the  name-based  FJ  semantics,  it  is  one  of  the  major  challenges  of 
our  translation. 

Featherweight  Java  is  Turing  complete;  it  is  easy  to  embed  a  A-calculus  in  it.  Nev¬ 
ertheless,  for  demonstration  purposes,  we  will  usually  augment  it  with  integers,  arith¬ 


metic,  and  simple  conditional  expressions.  Figure  [3T2| contains  a  sample  program  that 
demonstrates  many  of  FJ’s  features,  including  dynamic  method  binding  and  dynamic 
cast.  We  will  revisit  this  example  in  chapter  [5]  Although  Featherweight  Java  is  very 
restricted,  its  syntax  is  precisely  a  subset  of  Java.  That  is,  we  can  directly  compile  the 
classes  of  figure [3T2| with  javac.  By  adding  the  main  program  expression  to  a  static  main 
method,  we  can  run  the  program  and  verify  that  the  result  is  6. 
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fields  (Object)  =  •  (3.1) 


Cr( C)  =  class  C  extends  B{  Ci  fi;...Cn  fn;  K...  } 

fields  (B)  =  Bi  gi-..B,n  gm _  (3.2) 

fieldsi C)  =  Bi  g: . . .  Bm  gm,  Ci  fi . . .  Cn  fn 

CT(C)  =  class  C  extends  B  {  . . .  K  Mi . . .  Mn  } 

3j  :  Mj  =  D  m  (Dj  xi . . .  Dm  xm)  {  return  e;  } 
mtype(m,C)  =  Di . . .  Dm  —  D 
mbody( m,  C)  =  (xi . . .  xm,  e) 

Cr( C)  =  class  C  extends  B  {  . . .  K  Mi . . .  Mn  } 

m  not  defined  in  Mi ...  M„ 
mtype(m,  B)  =  Di . . .  Dm  —  D 

mbodyim,  B)  =  (xi ..  .xm,e)  ^ 

mtype{m,C)  =  Di . . .  Dm  —  D 
mbody( m,  C)  =  (xi . . .  xm,  e) 

Figure  3.3:  Auxiliary  functions  for  field  and  method  lookup 

3.2  Semantics 

The  semantics  of  Featherweight  Java  consists  of  a  set  of  typing  rules  and  a  small-step 
computation  relation.  To  express  both  of  these  cleanly,  a  few  auxiliary  definitions  are 
in  order.  Figure  [373]  define s  several  relations  that  describe  the  inheritance  of  fields  and 
the  dynamic  lookup  of  methods.  fields( C)  returns  the  sequence  of  all  the  fields  found 
in  objects  of  class  C.  The  symbol  V  represents  the  empty  sequence— class  Object  has 
no  fields  in  FJ.  Fields  are  assumed  to  have  distinct  names,  so  we  need  not  worry  about 
shadowing. 

The  relation  mtype(m,C)  finds  the  type  signature  for  method  m  in  class  C  by  search¬ 
ing  up  the  hierarchy.  Type  signatures  have  the  form  Di . . .  Dn  -»  Do.  mbodyi m,  C)  is  the 
same,  but  returns  the  names  of  the  formal  parameters  and  the  method  body  expres¬ 
sion.  These  relations  are  defined  inductively  on  the  class  hierarchy,  but  surprisingly, 
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C  <: C  (3.5) 

CT{ C)  =  class  C  extends  B  {...  }  B<:A 

- c<Ta -  (3'6) 

Figure  3.4:  Definition  of  the  subtyping  relation 


fleldsj C)  =  Pi  fi . . .  Dw  f n 
(new  C  (ei  ...en)).fi  —  e* 


mbodyj m,C)  =  (xi . . .  xn,  e0) _ 

(new  C  (ei...em)).m  (di . . .  dn)  — *  (3.8) 

[di/xi, . . . , dn/xn,  new  C  (ei . . .  em)/this]  e0 


C  <:  D _ 

(D)  new  C  (ei . . .  en)  —  new  C  (ei . . .  e„) 


(3.9) 


Figure  3.5:  Computation  rules 


the  base  case  is  not  Object.  Rather,  the  base  case  is  defined  in  rule  (|3.3[>  as  the  nearest 
super  class  containing  a  declaration  of  method  m.  If  m  is  not  a  method  of  class  C,  the 
relations  are  undefined. 

The  subtype  relation  <:  (figure  |3~4j>  is  the  reflexive,  transitive  closure  of  the  relation 


defined  by  the  super  class  declarations  (class  C  extends  B).  Igarashi,  Pierce,  and  Wadler 


(2001)  add  an  explicit  rule  for  transitivity;  this  is  unnecessary  and  would  complicate 


some  lemmas  in  chapter  [5] 

With  these  auxiliary  definitions,  the  dynamic  semantics  of  FJ  is  easily  specified;  ‘- 


is  a  small-step  reduction  relation  between  expressions.  Figure  3.5  contains  the  most 


important  rules.  Since  fields  are  immutable,  order  of  evaluation  is  unimportant  and 
unspecified.  Objects  are  represented  simply  as  new  expressions  with  their  field  initial¬ 
izers.  The  class  name  following  the  new  keyword  represents  the  dynamic  class  of  the 
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e  — ►  e' 

e.f i  — *  e'.fj 


e  — ►  e' 

e.m  (di . . .  dn)  — *  e'.m  (di . . .  d„) 


e.m  ( . . .  ef . . . )  — ►  e.m  (...e-...) 

et  —  < _ _ 

new  C  ( . . .  e* . . . )  — *  new  C  ( . . .  e  • . . . ) 


e  — ►  e' 

(C)  e  —  (C)  e7 


Figure  3.6:  Congruence  rules 


(3.10) 

(3.11) 

(3.12) 

(3.13) 

(3.14) 


object— it  does  not  change,  even  after  a  cast. 

A  field  reference  on  an  object  (rule  |3.7[>  reduces  to  the  field  initializer  expression 
corresponding  to  the  selected  field.  To  invoke  a  method  on  an  object  (rule|3.8),  we  first 
find  the  method  in  the  hierarchy,  searching  upward  from  the  class  (C)  that  created  the 
object.  Then,  we  substitute  the  actual  parameters  for  the  formal  parameters  and  the 
object  itself  for  this  and  continue  executing  the  body  of  the  method.  Finally,  a  cast  on 
an  object  succeeds  (rule  |3.9|  if  the  dynamic  class  (C)  of  the  object  is  a  subclass  of  the 
requested  class  (D). 

The  congruence  rules  (figure |3T>)  are  necessary  but  uninteresting.  They  enable  com¬ 
putation  within  expressions  that  are  not  themselves  redexes.  Variables  are  irreducible, 
so  none  of  the  reduction  rules  apply.  The  computation  and  congruence  rules  comprise 
the  complete  operational  semantics  of  Featherweight  Java. 

The  static  semantics  is  mostly  covered  by  the  typing  rules  for  expressions  (figure [3/7] 
on  the  facing  page).  The  judgment  T  I-  e  £  C  means  that  expression  e  has  type  C  in  the 
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rhxe  r(x) 


(3.15) 


r  G  e  G  c 
r  G  e.fj  G  D 

fields{ C)  =  Di  fi . . 

■  Dn  fn 

(3.16) 

r  G  e  G  c 

mtype(m,  C)  =  Di . 

■  ■  D  n  — ►  D 

r  G  e;  G  Cj 

Cj  <:  D,  ( Vi  G  { 1 . 

..n}) 

(3.17) 

r  G  e.m  (ei 

■  ■  ■  6ji)  £  D 

fields(C)  = 

Di  fi  -  -  -  Dn  fn 

T  G  e;  G  Cj 

QcDi  ( Vi  G  { 1 . 

..n}) 

(3.18) 

r  i-  new  C  (ei . .  ,en)  e  C 


r  G  e  G  D  D<:C 
r  h  (C)  e  G  C 


(3.19) 


r  l-  e  G  D  C  <:  D  C^D 
r  G  (C)  e  G  C 


(3.20) 


r  G  e  G  D  C^D  D^C 
r  G  (C)  e  G  C 


Figure  3.7:  Typing  rules  for  expressions 


context  of  T.  The  environment  T  maps  free  variables  x,  to  their  types  D,.  Since  FJ  has 
no  local  variables  or  nested  methods,  the  context  is  either  empty  at  the  top  level  or  it 
contains  bindings  for  the  formal  parameters  of  just  one  method. 

The  type  of  variable  reference  (rule|3.15~)  comes  directly  from  the  environment.  The 
type  of  a  selected  field  (rule  |3.16[>  is  retrieved  from  the  class  hierarchy.  To  check  a 
method  invocation  (rule  |3.17|,  we  look  up  the  type  in  the  hierarchy  above  the  static 
class  (C)  of  the  receiver.  All  of  the  argument  expressions  must  have  types  compatible 
with  the  method  signature.  Note  that  this  rule  assumes  that  method  signatures  are 
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K  —  C  (Bi  gx . . .  Brt  gn,  Ci  fi . . .  Cm  f m) 

{super(gx . . .  gn); 
this.fi  =  fi ; . . .  this.fm  =  fm;} 
fields(B)  =  Bi  gA  ...Bn  gn 
M,  ok  in  C  Vi  e  {1 ...  k} 

class  C  extends  B  {  Ci  f i ; . . .  Cm  fm;  K  Mi . . .  Mfe  }  ok 


xi  :  Di, . . . ,  xn  :  Dn,  this  :  C  h  e  e  E  E<:D 
CT( C)  =  class  C  extends  B  {  ...  } 
override( m,  B,  Di . . .  Dn  — •  D) 

D  m  (Di  xi . . .  Dn  x„)  {  return  e;  }  ok  in  C 


mtypejm,  B)  =  Ci . . .  Cn  -  Cp 
override{ m,  B,  Ci . . .  CM  —  Co) 


(3.24) 


-'BT  such  that  mtype{m,  B)  =  T 
override{ m,  B,  Ci . . .  Cn  —  Co) 


(3.25) 


Figure  3.8:  Well-typed  classes  and  methods 


invariant  up  the  hierarchy— we  will  check  that  property  elsewhere. 

The  three  different  rules  for  cast  expressions  deserve  some  explanation.  The  first 
(rule  |3.19)  is  an  upward  cast,  and  is  harmless.  The  second  (|3.2Q[>  is  a  downward  or 
dynamic  cast,  which  might  fail  at  runtime.  Of  course,  if  it  succeeds  then  the  expression 


has  the  requested  type  C.  Finally,  rule|3.21|covers  the  case  where  the  static  class  and  the 
requested  class  are  incomparable.  IgarashTTPierce,  and  Wadler  (2001)  call  this  a  stupid 
cast;  such  a  construct  is  not  valid  in  top-level  Java  programs,  but  may  arise  during 
the  course  of  reduction  and  must  be  assigned  a  type.  ClassicJava  was  unsound  as 


published  due  to  the  omission  of  stupid  casts.  Please  refer  to  Igarashi,  Pierce,  and 
Wadler  (2001}  for  further  explanation. 


The  typing  rules  for  expressions  are  not  the  whole  story.  Several  additional  con¬ 
straints  on  classes  and  methods  must  be  enforced;  they  are  covered  in  figure  [378]  The 
override  relation  (rules  |3.24|  and  |3.2  5[>  certifies  that  method  signatures  are  invariant 
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up  the  hierarchy.  In  other  words,  overriding  cannot  change  the  type  of  a  method— FJ 


does  not  support  overloading.  Rule  3.23  ensures  that  the  type  of  the  method  body  is 


compatible  with  the  signature.  Rule  |3 .2 2]  enforces  the  rigid  format  of  the  constructor: 
it  must  pass  the  initializers  for  inherited  fields  along  to  the  super  class  constructor, 
and  then  initialize  its  own  fields,  in  order.  Arbitrary  expressions  are  banned  from  the 
constructor. 

The  judgments  on  well-typed  classes,  methods,  and  expressions  are  all  decidable, 
and  sound  with  respect  to  the  operational  semantics.  Igarashi,  Pierce,  and  Wadler  (2001 1 
prove  the  standard  pair  of  preservation  and  progress  theorems.  Please  see  their  article 
for  the  detailed  proofs. 


Chapter  4 


Intermediate  Language:  Mini  JFlint 


Next,  we  need  a  sound  formalization  of  an  intermediate  language.  Building  on  a  typed 


A-calculus  (Barendregt  19921  is  an  appropriate  strategy  for  several  reasons.  First,  such 


languages  have  been  successful  in  type-based  compilers  for  Standard  ML  (Shao  and 


Appel  1995|[Morrisett  et  al.  1996).  Perhaps  this  is  not  surprising,  since  untyped  A-calculi 


had  been  used  in  functional  language  compilers  for  many  years.  Second,  Morrisett 


et  al.  (1999b)  developed  techniques  to  compile  System  F  all  the  way  to  typed  assembly 


language. 

Still,  it  was  not  clear  when  we  started  this  work  that  a  typed  A-calculus  would  be  suit¬ 
able  for  compiling  Java.  There  was  significant  precedent  for  encoding  object-oriented 
features  in  variants  of  F(0  (Bruce,  Cardellk_and  Pierce  1999;  Hofmann  and  Pierce  1994 


Abadi,  Cardelli,  and  Viswanathan  19961,  but  not  in  the  context  of  compilers. 


In  the  end,  using  Fu,  as  a  starting  point  was  clearly  a  good  choice.  Extended  with  the 
right  primitives,  and  expressed  in  either  continuation-passing  style  j Appel  1992)  or  A- 
normal  form  (Flanagan  et  al.  1993),  a  typed  A-calculus  does  indeed  resemble  a  low-level 
compiler  intermediate  language. 
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Kinds  k  ::=  Type  |  R1  |  k^>k'  |  {(1:\k)*} 

Types  r  ::=  a  |  A oc'.k.t  \  t  t'  \  {(Z  =  t)*}  \  r-l  \  |  Abs1  |  l :  r  ;  r' 

I  {t}  |  {r]>  |  luoc.'.K.  t  |  Voc.'.k.t  | 

Selectors  s  °  |  s-l 

Terms  e  \:=  x  \  \x  \  t .  e  \  e  e'  \  A av.K.e  \  e  [r]  |  injf  e 

|  case  e  of  (lx  =>  e)*  else  e  \  {(l  =  e)*}  \  e.l  \  fix [r]  e 

|  (cc.'.K  =  t,  e  :t')  j  open  e  as  (cxv.k,  x  :t)  in  e' 

|  fold  e  as  luav.K.T  at  A y::K.s[y] 

|  unfold  e  as  ijoc.-.k.  r  at  Ay::K.5[y] 

|  abort  [t] 

Figure  4.1:  Abstract  syntax  of  Mini  JFlint 


h:n,. ..,ln:rn  =  . . .  ln  :  rn ;  AbsHl-M 

1  = {Abs0} 


maybe  =  Acv::Type.  {some :  a,  none :  1 } 
some  =  A«::Type.  Ax :  a.  inj^^g6  01  x 
none  =  A«::Type.  inj^0anyebe  w  {} 

letx:r  =  e  in  e'  =  (A x:r.e')  e 


Figure  4.2:  Derived  forms  (syntactic  sugar) 


4.1  Syntax 


Figure [44]contains  the  BNF  grammar  for  the  abstract  syntax  of  Mini  JFlint.  It  is  based  on 
the  higher-order  polymorphic  A-calculus  F„h  described  independently  by  Girard  (1972 1 
and  jReynolds  (1974}.  Like  F0h  Mini  JFlint  is  an  explicitly-typed  calculus,  with  annota¬ 
tions  on  formal  parameters  and  terms  for  instantiating  polymorphic  functions.  In  addi¬ 


tion,  we  include  several  well-understood  features  such  as  existential  types  (Mitchell  and 
Plotkin  1988 1,  row  polymorphism  (Remy  19931,  records,  sum  types,  and  recursive  types. 
Several  convenient  syntactic  forms  are  derived  in  figure [472]  As  with  FJ,  we  augment  the 
language  with  integers  and  arithmetic  in  examples. 


For  compiler  writers,  the  key  features  to  notice  are  in  the  category  of  terms.  Ax :  t.  e 
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is  an  anonymous  function  with  formal  parameter  x  of  type  t  and  body  e.  Functions 
and  other  values  are  bound  to  lexically  scoped  variables  using  the  let  derived  form.  A 
function  call  is  expressed  as  e  c',  a  juxtaposition  of  the  function  expression  and  its 
actual  parameter. 

Mini  JFlint  supports  ordered,  labeled  records,  initialized  on  creation:  {l\  =  e\,  I2  =  62!- 
As  in  C,  the  memory  layout  is  determined  by  the  type,  so  that  field  offsets  are  known 
at  compile  time.  The  notation  e.l  selects  field  1  from  record  e.  Recursive  records  are 
expressed  using  a  lazy  fixed  point  operator  fix  [r]  e  where  r  is  a  sequence  of  record 
labels  and  their  types,  and  e  is  a  function  from  records  to  records.  The  fixed  point  is 
unrolled  as  needed  to  satisfy  field  selection  expressions.  In  an  imperative  language,  it 
would  be  implemented  using  assignment  to  create  a  recursive  data  structure. 

The  term  inj[  e  tags  the  value  of  e  with  the  label  l,  producing  a  value  of  type  r. 
This  implements  algebraic  data  types  as  in  functional  languages,  and  is  similar  to  the 
tagged  union  idiom  in  C.  The  case  expression  checks  the  tag  and  provides  access  to 
the  corresponding  tagged  value.  The  default  expression  else  e  permits  the  cases  to  be 
non-exhaustive. 

The  term  abort  [r]  aborts  computation,  but  is  otherwise  considered  to  have  type  r. 
We  use  this  to  model  a  failed  dynamic  cast.  In  the  operational  semantics,  evaluating 
abort  [r]  produces  an  infinite  loop,  so  that  “progress”  is  preserved.  In  an  actual  system, 
abort  would  correspond  to  throwing  an  exception. 

Language  mavens  are  probably  more  interested  in  the  typing  hierarchy.  As  in  F0h 
the  type  language  is  itself  a  simply-typed  A-calculus.  So-called  kinds  classify  types. 
Specifically,  Type  is  the  base  kind  of  those  types  that,  in  turn,  classify  terms.  The  arrow 
kind  #c=>k'  classifies  type  functions.  A  polymorphic  array  constructor,  for  example, 
would  have  kind  Type=>Type.  The  rules  for  forming  kinds  are  in  figure  |4.3|  on  the 
following  page. 

The  type  function  A cxv.k.  t  introduces  the  arrow  kind,  and  r  t'  eliminates  it.  That 
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I-  Type  kind 


(4.1) 


i-  Rl  kind 


(4.2) 


i-  k  kind  i-  k '  kind 
i-  k=>k'  kind 


(4.3) 


h  =  lj  =>  i  =  j  ( V i,  j  e  {1  ...n}) 
h  Ki  kind  (Vi  e  {l...n}) 

i-  {li ::  Ki...ln ::  Kn}  kind 


(4.4) 


Figure  4.3:  Formation  rules  for  kinds 


is,  (A oc.'.k.t)  t'  is  well-formed  if  t'  has  kind  k.  It  is  equivalent  to  r[a  :=  r'],  which 
denotes  the  capture-avoiding  substitution  of  r'  for  a  in  r.  Labeled  tuples  of  types  are 
enclosed  in  braces  {l  =  r  . . .}  and  have  tuple  kinds  {t  ::  k  . . .}.  The  mid-dot  syntax  r  ■  l 
denotes  selection  of  a  type  from  a  tuple. 

The  single  arrow  r^r'  is  the  type  of  a  function  expecting  an  argument  of  type  r  and 
returning  a  result  of  type  r'.  Our  implementation  supports  multi-argument  functions, 
but  for  the  purposes  of  formal  presentation,  we  simulate  them  using  curried  arguments 
(int— int— int).  Polymorphic  functions  are  introduced  by  the  capital  lambda  (A a:\K.e) 
which  binds  «  in  e.  This  term  has  type  V«::k.  t,  where  e  has  type  r  and  a  may  appear 
in  r.  Thus,  the  polymorphic  identity  function  is  written  as  id  =  Aa::Type.  A xwa.x  and 
has  type  V«::Type.  a^a.  An  application  of  id  to  the  integer  3  is  written  id  [int]  3.  The 
definitions  maybe,  some,  and  none  in  figure  |4.2|  are  good  examples  of  higher-order 
types  and  polymorphism. 

A  row  is  essentially  a  suffix  (or  tail)  of  a  record  type.  Intuitively,  rows  and  types  are 
distinct  syntactic  categories,  but  it  is  convenient  to  collapse  them.  Otherwise,  we  would 


need  to  distinguish  their  quantifiers.  Remy  (1993 )  introduced  a  kind  R  of  rows  where 
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i-  o  kind  env 


(4.5) 


i-  4>  kind  env  h-  k  kind 
i -  4>,  a ::  k  kind  env 


(4.6) 


f  ho  type  env 


(4.7) 


4>  h-  A  type  env  <f>  i-  t  ::  Type 
4>  hA ,x:t  type  env 


(4.8) 


Figure  4.4:  Formation  rules  for  environments 


L  is  the  set  of  labels  banned  from  the  row.  Abs1  is  an  empty  row  of  kind  R1,  and  1 :  r  ;  t' 
prepends  a  field  with  label  l  and  type  r  onto  the  row  r'.  The  row  formation  rules  \4.14 
and |4.15|  see  figure  pO] on  page  [36)  prohibit  duplicate  labels:  a  type  variable  a  of  kind 
Rim!  cannot  be  instantiated  with  a  row  in  which  the  label  m  is  already  bound.  Braces 
{ ■ }  denote  the  type  constructor  for  records;  it  lifts  a  complete  row  type  (of  land  R0)  to 
kind  Type.  The  row  syntax  is  reused  within  triangle  brackets  {  ■  }  to  denote  sum  types. 

Record  terms  are  written  as  a  sequence  of  bindings  in  braces:  Ui  =  e,  I2  =  e}.  Permu¬ 
tations  of  rows  are  not  considered  equivalent— the  labels  are  used  only  for  readability. 
This  means  that  record  selection  e.l  can  be  compiled  using  offsets  that  are  known  at 
compile-time.  We  sometimes  use  commas  and  omit  Abs1  when  specifying  complete 
rows  (see  the  derived  forms  in  figure  |4~2).  We  let  1  (read  ‘unit’)  denote  the  empty  record 
type. 

Row  kinds  can  be  used  to  encode  functions  that  are  polymorphic  over  the  tail  of  a 
record  argument.  For  example,  the  function  Ap::R!,!.  Ax :  {1 :  string  \p}.  print  x.l  can  be 
instantiated  and  applied  to  any  record  which  contains  a  string  l  as  its  first  field. 


Existential  types  (3c*::k.t)  support  abstraction  by  hiding  a  witness  type  Mitchell 
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i-<£  kind  env  =  k 

<J>  h  a  ::  k 


4>,  a ::  k  i-  t  ::  k' 

4>  h  A a\\K.  t  ::  k=>k' 


<3>  I—  ti  ::  k'=>k  4>  t-  T2  ::  k' 

$  h  Ti  T2  ::  k 


h  =  lj  =>  i  =  j  (Vi,  j  e  {1  ...n}) 

<i>  h  Tj  ::  Kj  (Vi  £  {1 ..  .n}) _ 

^  I—  {l\  =  T\  .  .  .lyi  =  Tn}  ..  {l\  ..  K\  .  .  .  ln  ..  Kn} 


4>\-  T  ::  {li"  Ki  .  .  ,ln"  Kn} 
$  h  T-ti  ::  Ki 


h  $  kind  env 
(J»  h  Abs;  ::  R; 


<3>  i—  r  ::  Type  <3>  I—  r'  :: 

::  Ri_U} 


(4.9) 


(4.10) 


(4.11) 


(4.12) 


(4.13) 


(4.14) 


(4.15) 


Figure  4.5:  Type  formation  rules 


and  Plotkin  19881.  They  are  introduced  at  the  term  level  by  a  package  ( oc.:k  =  r,  e :  t'), 


where  r  is  the  witness  type  (of  kind  k)  and  e  has  type  r'[«  :=  r].  The  existential  is 
eliminated  (within  a  restricted  scope)  by  open;  see  rule s|4. 2 6] and [4727] in  figure  |4~7| on 
page  [39] 


The  following  example  demonstrates  the  syntax  for  creating  and  opening  existential 
packages.  We  will  package  some  value  with  a  function  that  expects  a  value  of  the  same 
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$  h  Ti  ::  Type  $  I-  T2  ::  Type 
$  b  ti  — T2  ::  Type 


(4.16) 


$  h  r  ::  R0 
4>  b  {r}  ::  Type 


(4.17) 


$  b  r  ::  R0 
4>  b  {r}  ::  Type 


(4.18) 


4>,  a ::  k  b  r  ::  k 
4>  b  nav.K.  t  ::  k 


(4.19) 


4>,  a ::  k  b  t  ::  Type 
4>  b  V a::K.  r  ::  Type 


(4.20) 


4>,  a ::  k  b  r  ::  Type 
4>  b  3 cc:.k.  t  ::  Type 

Figure  4.6:  Type  formation  rules,  continued 


(4.21) 


type.  Then  we  will  hide  that  type  from  outsiders. 


let  xi :  (3«::Type.  {z :  a,  f:  string})  = 

(£::Type  =  int,  {z  =  42,  /  =  int2string} :  {z /^-string}) 
in  let  X2  '■  (3a::Type.  {z :  a,  f  :cx^ string})  = 

(y::Type  =  real,  {z  =  3.1 41  5,  /  =  real2string} :  {z  :y,  /:  y- string}) 

in  . . . 

Now,  the  packages  xi  and  X2  have  the  same  (existential)  type,  even  though  the  values 
inside  them  have  different  types  (int  and  real).  We  used  /I  and  y  in  this  example  to 
emphasize  the  scopes  of  type  variables  bound  in  each  existential  package.  Here  is  a 
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function  that  will  accept  x\,  X2,  or  any  similar  existentially- typed  value. 

Ay :  (3«::Type.  {z :  a,  /:  a-* string}), 
open  y  as  (<5::Type,  g\{z:5,  /:5  —  string}) 
in  g.f  g.z 

Because  we  packaged  a  method  with  a  private  value,  this  simple  example  even  has  the 
flavor  of  object-oriented  programming,  although  further  apparatus  is  needed  to  support 
dynamic  binding. 

Recursive  types  are  mediated  by  explicit  fold  and  unfold  terms.  These  so-called 
iso-recursive  types— a  term  first  used  by  Crary,  Harper,  and  Puri  (19991— simplify  type 
checking,  but  are  less  flexible  than  equi-recursive  types  unless  the  calculus  is  equipped 
with  a  definedness  logic  for  coercions  (Abadi  and  Fiore  _1 9 9 6 1 .  Since  we  use  recur¬ 
sive  types  at  higher  kinds,  the  syntax  for  folding  and  unfolding  them  deserves  some 
explanation.  Suppose  we  wish  to  encode  the  following  mutually  recursive  type  abbrevi¬ 
ations: 


type  even  =  maybe  {hd  :  int,  tl : odd} 
type  odd  =  {hd  :  int,  tl  :even} 

The  solution  is  expressed  as  the  fixed  point  over  a  tuple: 

t  =  pa::{even  ::Type,  odd::Type}. 

{even  =  maybe  {hd  :  int,  tl :  a-odd}, 
odd  =  {hd  :  int,  tl :  a -even}} 

Now,  the  two  recursive  types  are  expressed  as  t -even  and  t -odd.  There  are,  however,  no 
type  equivalence  rules  for  reducing  t  ■  even;  a  term  having  this  type  must  first  be  coerced 
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4>  b  A  type  env  A(x)  =  r 
<J>;A  t-  x:t 


(4.22) 


4>;  A  i-  e :  r  4>  b  t  =  t'  ::  Type 
4>;A  i -  e:r' 


(4.23) 


4>  b  t  ::  Type  4>;  A,  x :  r  b  e  :  t' 
4>;Ab  (Ax :  t.  e) : 


(4.24) 


4>;  A  b  e\  :t'-'T  4>;Ab62  :t' 

4>;  A  b  ei  62  :  t 


(4.25) 


4>,  cx ::  k  b  r  ::  Type  4>  b  r'  ::  k 

4>;  A  b  e\r[(x  :=  t']  (4.26) 

4>;Ab  («::k  =  r',  e :  r) :  3«::k.  r 

4>;  A  b  e :  3cx::k.  t  4>  b  t'  ::  Type 

4>,  of ::  k;  A,x  :  r  b  e' :  r'  «  f  dom(4>)  (4.27) 

4>;  A  b  open  e  as  (a::K,  x :  r)  in  e' :  r' 

Figure  4.7:  Term  formation  rules 


to  a  type  in  which  t  is  unfolded.  We  allow  unfolding  of  recursive  types  within  a  tuple 
by  specifying  a  selector  after  the  at  keyword.  Selectors  are  syntactically  restricted  to 
a  (possibly  empty)  sequence  of  labeled  selections  from  a  tuple.  The  syntax  A y::K.s[y] 
allows  identity  (Ay::x.y),  one  selection  (\y::K.y-h),  two  selections  (Ayr.K.y-h-h),  and 
so  on.  The  formation  rules  (|4.33|and|4.34|— see  figure|4~8lon  page[4T)  further  restrict  the 
selectors  to  have  a  result  of  kind  Type.  Thus,  if  e  has  type  f -odd,  then  the  expression 


unfold  e  as  t  at  Ay::{even  "Type,  odd  ::Type}.  y-odd 


has  type  { hd  :  int,  tl :  f -even}.  For  recursive  types  of  kind  Type,  the  only  allowed  selector 
is  identity,  so  we  omit  it.  We  sometimes  also  omit  the  as  annotation  where  it  can  be 
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readily  inferred. 


4.2  Semantics 


The  semantics  of  Mini  JFlint  consists  of  several  kinds  of  static  judgments,  plus  a  small- 
step  operational  semantics.  In  describing  the  syntax,  we  already  referred  to  several  of 
the  typing  rules;  now  we  will  introduce  them  properly.  Figure  pO]  on  page  [34]  defines 
the  judgment  t-  k  kind  for  well-formed  kinds.  The  rules  are  quite  simple;  they  ensure 
only  that  tuple  kinds  have  distinct  labels. 

Since  both  types  and  terms  have  free  variables,  we  need  environments  for  each.  We 
use  <F  for  the  kind  environment  (mapping  type  variables  to  their  kinds)  and  A  for  the 
type  environment  (mapping  term  variables  to  their  types).  The  judgments  defined  in 
figure  [4 ~A\  ensure  that  both  sorts  of  environments  are  well-formed. 

The  judgment  4>  i-  r  ::  k  states  that,  in  the  context  of  <F,  the  type  r  has  kind  k. 
Any  free  variables  in  r  must  be  in  the  domain  of  the  environment  <F.  The  rules  for  this 


judgment  are  in  figures  |4.5|  and  |4.6|  They  are  all  quite  standard,  but  the  previously 
noted  rules  for  forming  rows  and  records  are  the  most  interesting.  Because  there  are 
tuples  and  functions  at  the  type  level,  we  need  a  notion  of  equivalence  beyond  syntactic 
congruence.  The  equality  relation  on  types  4>  i-  T\  =  T2  ::  k  is  defined  in  figures  [479]  on 
page 


42  and  4.f0 


on  page 
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The  typing  rules  for  the  term  language  are  in  figures  |4.7|  and  |4.8|  The  judgment 
<f>;  A  i-  e  :  r  means  that  expression  e  has  type  r,  assuming  that  any  free  variables  are  in 
the  domain  of  A.  The  kind  environment  <F  is  needed  because  some  terms  introduce  new 
type  variables.  Most  of  the  rules  are  standard,  but  several  warrant  further  explanation. 

Rule  |4. 2  3~1  allows  the  substitution  of  an  equivalent  type  anywhere  in  a  derivation;  it 
is  the  only  typing  rule  that  is  not  syntax-directed.  To  ensure  that  the  term-level  fixed 
point  is  used  only  for  constructing  records,  the  type  annotation  in  fix  [r]  e  is  really  a 
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li  =  lj^i  =  j  (Vi,  j  G  {l...n}) 

4»;A  i-  (Vi  G  {l...n}) _ 

<f>;  A  b  {ii  =e\...ln  =  en} :  (h  :  Ti . . .  ln  :  Tn} 


4>;  A  i-  e:  {h  :ti  ;  ..  ,ln  :rn  ;  r} 
<f>;A  b  e.i, :  t, 


4>;  A  i-  e\ {t}^{t}  4>  b  t  ::  R° 

4>;  A  t-  fix[T]  e  :  {t} 


<f>  b  CiiiTi;  ::  Type  4>;A  b  e:r, 

<f>;A  h-  inj).4,Ti;-l":Tn;Tj>  e:  ...ln:Tn;r} 


1)  =  If  =>j  =  f  (Vj,/e{l...m}) 

4>;A  i-  e:  Cii  :ti  ;  ...in:Tn;T}  4>;  A  b  e'  :t' 

3i  g  {1 . .  .n}  :  ij  =  !'■  and  4>;  A,Xj  :  t*  i-  <2j :  t'  ( Vj  g  {1 . . .  m}) 
<f>;  A  b  case  e  of  (X-  x;  e,)  ,e!  l  "m!  else  e' :  r' 


h  r  ::  k  4>  b  ts  ::  K=>Type  $;Ahc:Ts  (t[«:=/j«::k.t]) 
4>;  A  b  fold  e  as  nav.K.  r  at  ts  :  ts  (nav.K.  t) 


$,oc:ki-t::k  4>  i-  ts  ::  K^Type  4>;  A  b  e  :  t5  (nav.K.  t) 
4>;  A  b  unfold  e  as  nav.K.  t  at  r5  :  r5  (r[a  :=  nav.K.  r]) 


4>,  a  v.  k\  A  b  e :  t  4>  b  A  type  env 
$;Ah  (A av.K.e) :  V av.K.T 


4>;  A  b  e:  Vav.K.r  4>  b  t' v.  k 
<J>;Ah  e  [t']:t[oc=  t'] 


4>  b  t  ::  Type  4>  b  A  type  env 
4>;  A  b  abort  [r] :  r 


(4.28) 


(4.29) 


(4.30) 


(4.31) 


(4.32) 


(4.33) 


(4.34) 


(4.35) 


(4.36) 


(4.37) 


Figure  4.8:  Term  formation  rules,  continued 
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$  h  Ti  ::  k i  <3>,  aw  k i  I-  T2  ::  K2 
4>  h  (Aav.Ki.  T2)  r  1  =  T2 [ of  :=  Ti]  ::  K2 


(4.38) 


4>  h  t  ::  k=>k'  a  f  dom(4>) 
4>  1-  A av.K.T  a  =  t  ::  k^>k' 


(4.39) 


li  =  lj=>i  =  j  (Vi,  j  e  {1  ...n}) 

4>  1-  Tj  ::  Kt  (Vie  {1 . .  .n})  (4.40) 

4>  h  {h  =ti... ln  =  Tn}-k  =  Ti  ::  Ki 

li  =  lj=>  i  =  j  (Vi,  j  e  {1 .  ..n}) 

4>  h  t  ::  _  (4.41) 

4>  h  {ii  =T-h...ln  =  T-ln}  =  t  ::  {li::Ki...ln:\Kn} 


4>  h  t  ::  k 
4>  b  r  =  r  ::  k 


(4.42) 


4>  1-  ti  =  T2  ::  k 
4>  h  T2  =  Ti  ::  k 


(4.43) 


4>  1—  Ti  =  T2  ::  k  4>  1-  T2  =  T3  ::  k 
4>  h  ti  =  T3  ::  k 


(4.44) 


Figure  4.9:  Type  equivalence  rules 


row;  see  rule  4.30 


The  rule  for  case  expressions  \432\  ensures  that  the  listed  labels  are  all  disjoint  and 
members  of  the  sum  type  being  eliminated.  The  labeled  cases  need  not  be  exhaustive;  we 
use  the  else  clause  in  the  implementation  of  dynamic  cast  and  class  linking  in  chapter[5] 
The  operational  semantics  are  defined  in  figurespnT|on  page|45]and|4.12|on page|46| 
The  grammar  for  values  v  defines  a  subset  of  the  terms  that  are  irreducible;  these 
include  abstractions,  records  of  values,  tagged  values,  and  packed  or  folded  values. 
There  is  just  one  dynamic  judgment:  e  e'  means  that  term  e  reduces  to  term  e'  in 
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4>,  « k  i-  Ti  =  T2  ::  k' 

4>  h  \a::K.T\  =  A«::k.T2  ::  k^>k' 


(4.45) 


4>  I-  Ti  =  r1  ::  k'^>k  4>  i-  T2  =  t2 

::  k' 

4>  1-  Ti  T2  =  t[  t2  ::  K 

li  =  lj=>i  =  j  (Vi, j  6  {l...n}) 

4>  i -  Ti  =  t[  V.  Ki  (Vi  e  {1  ...n}) 

4>  l-  {li  =  Ti . . .  ln  =  Tn}  =  {h  =  t[  . . . 
■■  { ii ::  i<\ . . .  ln  ::  Kn } 

In  =  T^} 

4>  i-  t  =  t'  ::  {li:\Ki...ln::Kn} 

4>  t-  r-ij  =  T'-ij  ::  ^ 

4>  I-  Ti  =  t[  ::  Type  4>  i-  T2  =  r2  : 

:  Type 

4>  h-  Ti  —  T2  =  t[-+  To  ::  Type 

4>  i-  Ti  =  t[  ::  Type  4>  t-  T2  =  r2  : 

.  pLu{£} 

4>  i—  l:T\  \T'2  =  /. :rj  ;  t  2  ::  R1  '7| 


(4.46) 


(4.47) 


(4.48) 


(4.49) 


(4.50) 


4>  b  t  =  t'  ::  R° 

4>  h  {t}  =  {t'}  ::  Type 


(4.51) 


4>  b  t  =  t'  ::  R° 

4>  h  {t}  =  {t'}  ::  Type 


(4.52) 


Ti  =  T2  ::  k 

4>  h  nav.K.T i  =  ia(x::k.T2  ::  k 


(4.53) 


4>, k  i-  Ti  =  T2  ::  Type 

4>  h  =  V  a:\K.T2  ::  Type 


(4.54) 


4>,  « ::  k  h-  Ti  =  T2  ::  Type 

4>  h  =  3«::k.T2  ::  Type 


(4.55) 


Figure  4.10:  Type  equivalence  rules,  continued 
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one  step.  All  the  interesting  reduction  rules  are  in  figure  4.11 


Surprisingly,  the  recursive  record  fixed  point  (fix  [r]  e)  is  treated  as  a  value.  It  is 


unrolled  only  when  it  is  the  subject  of  a  field  selection;  see  rule|4.58|  The  abort  primitive 
is  modeled  as  an  infinite  loop,  as  explained  previously. 


4.3  Properties 

This  formalization  of  our  intermediate  language  enjoys  several  essential  properties. 
First,  the  static  typing  judgments  are  decidable;  this  is  proved  with  the  aid  of  the  fol¬ 
lowing  lemmas. 


Lemma  1  (Normalization)  Type  reductions  are  strongly  normalizing. 


Proof  sketch  The  type  equivalence  judgments  can  be  read  left-to-right  as  reductions.  To 
demonstrate  that  these  reductions  are  strongly  normalizing,  we  view  the  type  language 
as  a  simply-typed  A-calculus  itself,  extended  with  records  (tuples),  lists  with  labeled 
elements  (rows),  a  base  type  (Type)  and  several  constants  (-»,{■},(■  }).  The  binding 
operators  (p,  V,  3)  are  also  constants,  since  they  are  neither  introduced  nor  eliminated 
by  any  reduction  rule.  Standard  proofs  for  strong  normalization  of  the  simply-typed 
A-calculus— by  Goguen  (19951,  for  example— can  be  adapted  to  this  type  language.  □ 


Lemma  2  (Confluence)  Type  reductions  are  confluent. 


Proof  sketch  As  above,  we  can  adapt  a  standard  proof  for  confluence  of  the  simply- 
typed  A-calculus.  □ 


Theorem  1  (Decidability)  All  static  judgments  in  the  previous  section  are  decidable. 

Proof  Judgments  for  the  formation  of  kinds,  kind  environments,  types,  and  type  envi¬ 
ronments  are  all  syntax-directed  and  trivially  decidable. 
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Values  v  ::=  A x:r.e  |  {( l  =  u)*}  |  fix[r]  e  |  inj j  v  \  A av.K.e 

\  < cc.:k  =  r,  v  :t')  |  fold  v  as  p«::k.t  at  Ay::/c.5[y] 


(A x:T.e)  v  ^  e[x  :=  v ] 


(4.56) 


( { (l  —  t7l  ■  ■  ■  In  —  Vn})-li  Vi 


(4.57) 


(fix[T]  e).l (e  (fix[r]  e)).l 


(4.58) 


U  =  l'k 

case  inj^1'Tl’"'t”'T"’T^  v  of 

( lj  Xj  =>  ej)je{i-..m}  e|se  e' 

eidxk  ■=  v  ] 


(4.59) 


U  =t=  l'k  (Vfe  G  {1 ..  .m}) 
case  injJifl-Ti:-£"-T"’T>  v  of 

( l'j  Xj  =>  eJ)ie{1...m}  e|se  e' 


(4.60) 


unfold  (fold  u  as  t  at  ts)  as  t  at  ts  u 


(4.61) 


(A«::k\  e)  [r]  e[a  :=  t] 


(4.62) 


open  {a::K  =  r' ,  v  :  r)  as  (cv::k,  x  :t)  in  e'  (4.63) 

e'[«  :=  t'][x  :=  u] 


abort  [t]  abort  [t] 


(4.64) 


Figure  4.11:  Values  and  primitive  reductions 
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e  e' 


(4.65) 


e-^  e' 
v\  e  vi  e' 


(4.66) 


e  e' 

{l\  =  V±, ,  li~i  =  Vi-\,  li  =  e,  li+i  =  fij+i, . . . ,  In  =  <?n}  (4.67) 

{l i  =vi,...,  U- 1  =  Vi- 1,  U  =  e' ,  U+ 1  =  e,+i, . . . ,  ln  =  en} 


e  e' 
e.l  e'.i 


(4.68) 


e' 

inj[  e  inj[  e' 


(4.69) 


e  e' 

case  e  of  {li  Xi  =>  e,)ie{1-m|  else  e77  (4.70) 

case  e'  of  (Ij  x*  =>  ej)l(E{  1-m}  else  e" 


e' 

fold  e  as  t  at  Ti  ^  fold  e'  as  r  at 


(4.71) 


e' 

unfold  e  as  r  at  r5  ^  unfold  e'  as  r  at  r5 


(4.72) 


e  e' 

e  [r]  e'  [r] 


(4.73) 


e  e' 

(a\-.K  =  r,  e:r')  ( oc.:k  =  t ,  e'  :t') 


(4.74) 


e' 

open  e  as  («::/<,  x:r)  in  ei  (4.75) 

open  e'  as  («::;<:,  x:r)  in  ei 


Figure  4.12:  Congruence  rules 
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Type  equivalence  is  not  syntax-directed.  Since  reductions  are,  however,  strongly 
normalizing  (lemma  [l)  we  have  an  algorithm  for  deciding  type  equivalence:  reduce  Ti 
and  T2  to  normal  form,  then  test  whether  they  are  syntactically  congruent  (modulo 
renaming  of  bound  variables). 

Term  formation  is  syntax-directed  except  for  rule  (|4.23|,  which  accounts  for  type 
equivalences.  If  an  algorithm  always  reduces  types  to  normal  forms,  then  the  types  of 
two  different  expressions  can  be  checked  for  syntactic  congruence,  and  rule  (|4.23|  is 
not  needed.  □ 

Next,  we  give  a  detailed  proof  that  the  type  system  of  Mini  JFlint  is  sound  with 
respect  to  its  operational  semantics.  This  is  expressed  as  the  usual  pair  of  theorems: 
subject  reduction  and  progress.  The  first  means  that  each  reduction  preserves  the  type 
of  an  expression.  The  second  guarantees  that  a  well-typed  expression  is  either  a  value 
already,  or  it  can  be  further  reduced.  Note  that,  because  we  defined  the  reduction  of 
abort  as  an  infinite  loop,  even  programs  which  encounter  an  abort  still  make  progress. 


Lemma  3  (Substitution  of  terms)  If  4>;  A  i-  e' :  r'  and  4>;  A ,x:r'  i-  e :  r,  then  4>;  A  i- 
e[x  :=  e']  :r. 


Proof  By  induction  on  the  derivation  of  4>;  A,  x :  t'  h-  e  :  t.  □ 

Lemma  4  (Substitution  of  types)  If  4>  i-  t'  ::  k  and  <&,  a::  k;  A  I -  e\r,  then  4>;A[a  :  = 
t']  i-  e[a  :=  t']  :  t[«  :=  t']- 

Proof  By  induction  on  the  derivation  of4>,a::K;Ai-e:T.  □ 

Theorem  2  (Subject  reduction)  Ife^e'  and  4>;  A  I -  e  :  t  then  4>;  A  b  e' :  r. 

Proof  By  induction  on  the  derivation  of  e  e' . 


Case  (4.56^  (Ax :  r.  e)  v  e[x  :=  v].  From  antecedent,  4>;  A  I-  (Ax :  r.  e)  v  :  t'. 
By  inversion  on  (|4 . 2  5 [>  and  \4.24\,  4>;  A,  x :  r  i-  e :  r',  and  4>;  A  h-  v  :  r.  Finally, 

4);  A  i -  e[x  :=  v]  :t'  using  lemma [3] 
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Case  (|4.5  7)  (Ui  =  v\ . .  .ln  =  vn}).U  vt.  From  antecedent, 

4>;  A  b  {l\=v\ . .  .ln  =  vn}.k :  r.  By  inversion  on  (|4.29[>  and  (|4.28|,  $;Ah  Vi :  r. 


Case  (|4.58)  (fix [r]  e).li  (e  (fix [t]  e)).U.  From 
antecedent,  4>;A  b  (fix [r]  e).li'.Ti.  By  inversion  on  {429}, 


4>;  A  b  fix  [t]  e:{l\:Ti; ...  ln-Tn  ;t'}.  By  inversion  on  *  4.30 ' 


<f>;  A  b  e  \  and  r  =  {h  :ti  ;  .. .  ln: Tn;T'}.  Using  {4.25}, 


4>;  A  b  e  (fix  [r]  e) :  {l\ :  Ti ;  . . .  ln  :rn  ;t'}.  Then,  using  {429), 

<f>;  A  b  (e  (fix  [r]  :  r,. 

Case  (|4.59fr  case  injj-.Jl'Tl’"'in'Tn’T^  v  of  (('•  xj  =>  ej)j^D-'m}  else  e’  ^ 

£k[xk  ■=  v]  where  It  =  l'k.  From  antecedent,  $;A  h  case  . . .  :  t'.  By  inversion  on 


(4.32  ',  <t>;  A,Xk  :t*  i-  ey_ :  t'  and  $;Ah  injjy  v  :  (it  :ti  ;  . .  .ln :  Tn  ;t}.  By  inversion 
on  {421}  and  lemma[3]  4>;  A  i-  \=  v ]  :t'. 


Case  (|4.60E  case  inj;-.Zl 'Tl v  of  ( l'j  Xj  =>  e|se  e>  ^  e> 


where  i,  =/=  l'k,\/k  e  {1 . . .  m}.  From  antecedent,  4>;  A  b  case  . . .  :t'  .  By  inversion 
on  {422},  4>;  A  i-  e' :  t'. 


Case  (|4.61fr  unfold  (fold  v  as  t  at  rs)  as  t  at  ts  v.  From  antecedent, 
4>;  A  b  unfold  . . .  :  r' .  By  inversion  on  {424}  and  {423},  r  =  To, 

t'  =  ts  (t0 [a  :=  t] ),  and  4>;  A  f-  v  :rs  (t0[«  :=  t] ). 


Case  (|4.62fr  (A av.K.e)  [t]  e[cv  :=  t].  From  antecedent, 

4>;  A  b  (A a:\K.e)  [t]  :  t' .  By  inversion  on  {426}  and  {425},  t'  must  be  in  the 
form  of  Ti[«  :=  t],  and  4>,  a ::  k\  A  i-  e  :  ti,  and  4>  i -  t  ::  k.  Using  lemma  [4] 
4>;  A  b  e[a  :=  t]  :ti[cx  :  =  t],  i.e.  4>;A  b  e[a  :=  t]:t'. 


Case  (|4.63fr  open  {av.K  =  t',  v  :t)  as  («::k,  x:t)  in  e’  ^  e'[a  :=  t'][x  :=  v]. 
From  antecedent,  $;A  h  open  . . .  :  To.  By  inversion  on  {427}, 

4>;A  b  ( am.m.K  =  T v  :t)  :3ct.:k.t,  4>,  « ::  k\  A,x  :  t  b  e' :  tq,  and 
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4>  I-  To  ::  Type.  By  inversion  on  (|4.26),  4>;  A  h-  v  :t[«  :=  r'].  Using 
lemma[4]  4>;  A,  x :  r[a  :=  r']  i-  e'[a  :=  t']  :ro[«  :=  t'].  Using  lemma[3] 

<i>;  A  I-  e'[a  :=  r'][^  :=  v]  :ro[«  :=  r'].  This  is  equivalent  to  To  since  a  is  not 
free  in  To- 

Case  {4-64}  abort  [r]  abort  [t].  Trivial. 


Case  (4j65)  e  ez  er  62  where  e  e'.  From  antecedent,  4>;  A  1-  e  eo  :  t.  By 
inversion  on  (|4 . 2 5 ) ,  $;  A  h  e :  r'  — r;  and  4>;  A  h  62  :  t'.  By  induction  hypothesis, 


4>;  A  1-  e' :  t'  —  t.  Using  (4.25  ',  4>;  A  h  e'  62  :  t. 


The  cases  for  all  the  remaining  congruence  rules  l4.66H4.7~a)  follow  the  same  pattern: 
invert  some  typing  rule,  apply  induction  hypothesis,  then  apply  the  same  rule.  □ 


Lemma  5  (Canonical  forms)  If  v  is  a  value  and  4>;  A  h-  v  :  r  then  v  has  the  canonical 
form  given  by  the  following  table. 


T 

V 

Tl-T2 

AxiTi.e 

Ui :  Ti ;  . .  .ln:Tn\r'} 

{l\  =  V\, ...  ,ln  =  Vrii  ■■  ■} 

or  fix [ii  :ti  ;  ...ln:Tn\ r'\e 

Oi  :ti  ;  ...In-.Tn] t'} 

inj l  v' 

s[pa\:K.  r'] 

fold  v'  as  pav.K.r'  at  A y::K.s[y] 

V OC.'.K.  t' 

A oc.:k.  e 

3 oc:.k.  t' 

(cc.-.k  =  t",  v':t') 

Proof  By  inspection,  using  lemma [2]  □ 

Theorem  3  (Progress)  If  4>;  °  1-  e  :  r  then  either  e  is  a  value  or  there  exists  an  expression 


e'  such  that  e  e' . 
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Proof  By  induction  on  the  derivation  of  <t>;  o  i-  e :  r. 

Case  (|4.22)  impossible,  since  environment  is  empty. 
Case  (|4.23)  direct  application  of  induction  hypothesis. 
Case  (|4.24)  Xx :  r.  e  is  a  value. 


Case  (|425)  <1>;A  i-  e\  ez'-T  where  4>;A  h  ei'.T'  —  T.  By  induction  hypothesis, 
there  are  three  cases:  (1)  e\  and  ez  are  both  values.  Using  lemma[5]  e\  must  have 
the  form  Xx-.T.e.  Using  (|4.56),  ( Xx:r.e )  v  e[x  :=  v].  (2)  e\  is  a  value  and 
ez  e'z\  use  (|4.66|.  (3)  e\  e\ ;  use  (|4.65  '. 


Case  (|4.26)  $;A  i-  (cc.'.k  =  t' ,  e  :  r) :  3(x::k.  t.  By  induction  hypothesis,  there  are 
two  cases:  (1)  e  is  a  value;  then  <«::k  =  t',  e:r)  is  a  value.  (2)  e  e'\  then  use 
(474). 


Case  ((427)  4>;A  i-  open  e  as  (<x::k,  x:t)  in  e' \t' .  By  induction  hypothesis, 
there  are  two  cases:  (1)  e  is  a  value  of  type  3 cx::k.  r.  By  lemma  [5]  it  has  the  form 
{a\\K  =  r' ,  e\r)\  use  {4.63).  (2)  e  e'\  use  {4.75  >. 


Case  (|4.28)  4>;  A  i-  {l±  =  e\ . . .  ln  =  en} :  {li :  Ti . . .  ln  :th}.  By  induction  hypothe¬ 
sis,  there  are  two  cases:  (1)  e\...en  are  all  values;  then  {li  =  e\ . . .  ln  =  en}  is  a 


value.  (2)  ei  ^  e for  some  i;  use  (14.67). 


Case  ((429)  4>;A  i-  e.li'.Ti.  By  induction  hypothesis,  there  are  three  cases:  (1)  e 
is  a  value,  and  by  lemma [5]  it  has  the  form  {li  =  v\  ...ln  =  vn}.  Then,  progress 
can  be  made  using  rule  (|4.57).  (2)  e  is  a  value,  and  by  lemma  [5]  it  has  the  form 
fix  [r]  e;  then  use  rule  (|4. 58).  (3)  e  e'\  use  (|4.68). 


Case  (|4.30)  fix  [r]  e  is  a  value. 


Case  (|4.31)  $;A  h  inj/^.  e :  r.  By  induction  hypothesis,  there  are  two  cases:  (1)  e 


is  a  value;  thus  inj^  e  is  a  value.  (2)  e'\  then,  use  (4.69 '. 
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Case  {4-32}  4>;A  h-  case  e  of  ( T;  Xj  =>  e/)J'e*1'"m*  e|se  e'  -  T'  gy  induction  hy¬ 
pothesis,  there  are  two  cases:  (1)  e  is  a  value.  According  to  lemma  [5]  it  has  the 
form  inj^  v.  Thus,  either  (4.59'  or  (4.60'  applies.  (2)  e  ^  e'\  use  (4.70[l. 


Case  <433)  <1>;  A  i-  fold  e  as  t  at  ts\ts  t.  By  induction  hypothesis,  there  are 
two  cases:  (1)  e  is  a  value;  then  fold  e  as  r  at  r5  is  a  value.  (2)  e  ^  e'\  then  use 

<TtT). 


Case  <434)  $;At-  unfold  e  as  /j«::k.  t  at  t5  :  t\  By  induction  hypothesis,  there 
are  two  cases:  (1)  e  is  a  value  of  type  rs  (p«::k.  t).  By  lemma [5]  it  has  the  form 
fold  v  as  /jcv::k.  t  at  r5— use  <4.61).  (2)  e  e'\  then  use  <4.72). 


Case  <435)  A cx::k.  e  is  a  value. 


Case  <436)  A  i-  e  [t']:t[«  :=  t'],  where  4>;  A  h  e:M (xv.k.t.  By  induction 
hypothesis,  there  are  two  cases:  (1)  e  is  a  value.  By  lemma  [5]  it  must  have  the 
form  A(x::k.  e'\  use  <4.62).  (2)  e  e'\  use  <4.73  '. 


Case  <437)  4>;  A  i-  abort  [r] :  r.  Evaluates  to  abort  [r]  using  <4.64) 


□ 


Chapter  5 


A  Type-Preserving  Translation 


In  the  preceding  two  chapters,  we  formally  defined  a  source  language  (Featherweight 
Java)  and  an  intermediate  language  (Mini  JFlint).  This  chapter  is  devoted  to  translating 
one  to  the  other. 

We  will  begin  by  describing  and  formalizing  our  basic  object  encoding  in  sections [5TT| 
and|5.2[  In  section[5T3|  we  give  a  type-directed  translation  of  FJ  expressions.  Inheritance, 


overriding,  and  constructors  are  examined  as  part  of  the  class  encoding  in  section  5.4 


formalized  in  section  [575]  Next,  section  [576]  covers  linking  and  section  [5/7]  discusses 
separate  compilation.  Many  aspects  of  the  translation  are  mutually  dependent,  but  we 


believe  that  this  ordering  yields  a  reasonably  coherent  explanation.  Finally,  section [578 
contains  proofs  of  important  properties,  and  section  [T9]  considers  related  work. 


5.1  Self  application 

The  standard  implementation  of  method  invocation  using  records  functions  is  called 
self-application  (Kamin  19881.  In  a  class-based  language,  the  object  record  contains 
values  for  all  the  fields  of  the  object  plus  a  pointer  to  a  record  of  functions,  traditionally 
called  the  viable  or  method  suite.  The  vtable  of  a  class  is  created  once  and  shared 
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among  all  objects  of  the  class.  The  functions  in  the  vtable  expect  the  object  itself  as  an 
argument.  Suppose  class  Point  has  one  integer  field  x  and  one  method  getx  to  retrieve 
it.  Ignoring  types  for  the  moment,  the  term  po  =  {vtab  =  {getx  =  Aself.  (self.x) } ,  x  =  42} 
could  be  an  instance  of  class  Point.  The  self-application  term  po-vtab.getx  po  invokes 
the  method. 

What  type  should  we  assign  to  the  self  argument?  The  typing  derivation  for  the 
self-application  term  forces  it  to  match  the  type  of  the  object  record  itself. 

4>;  A  b  po :  {vtab :  {getx :  r^int},  x :  int} 
f;Ah  po-vtab :  {getx :  r— int} 

4>;  A  b  po.vtab.getx :  r  — int  4>;  A  b  po  :  t 

4>;  A  h  (po-vtab.getx  po) :  int 

That  is,  well-typed  self-application  requires  that  po  have  type  r  where 

r  =  {vtab :  {getx :  r^int},  x :  int} 

Because  r  appears  in  its  own  definition,  the  solution  must  involve  a  fixed  point.  The 
recursive  types  of  Mini  JFlint  are  sufficient  because  augmenting  the  code  with  fold  and 
unfold  annotations  enables  a  proper  typing  derivation.  Let  the  type  of  self  in  this  ex¬ 
ample  be 

Tpt  =  pself::Type.  {vtab:  {getx : self^int},  x : int} 


Then,  we  need  to  (1)  insert  an  unfold  inside  the  method,  before  accessing  x,  and  (2)  fold 
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entire  object  record. 

pi  =  fold  {vtab  =  {getx  =  Aself :  rvt.  (unfold  self) .x } ,  x  =  42} 
as  Tpt 

This  object  term  is  indeed  well-typed.  The  new  self-application  term  must  unfold  the 
object  before  fetching  its  vtable:  (unfold  pi). vtab. getx  p\. 

This  is  a  promising  start,  but  now  suppose  that  class  ScaledPoint  extends  Point  with 
an  additional  field  and  method.  The  type  of  an  object  of  class  ScaledPoint  would  be: 

rsp  =  pself::Type.  {vtab :  {getx :  self^int,  gets  :  self^int},  x:int,  s:int} 

How  can  we  relate  the  types  for  objects  of  these  two  classes?  More  to  the  point,  how  can 
we  make  a  function  that  expects  a  Point  also  accept  a  ScaledPoint?  Traditional  models 
employ  subsumption,  but  (1)  Tsp  is  not  a  subtype  of  Tpt,  so  some  rearrangement  is 
necessary;  and  (2)  we  decided  to  exclude  subtyping  from  our  intermediate  language— 
we  would  prefer  to  use  explicit  (but  erasable)  type  manipulations. 

Java  programmers  distinguish  the  static  and  dynamic  classes  of  an  object.  The 
type  annotations  on  formal  parameters,  local  variables,  and  fields  all  indicate  the  static 
classes  of  the  referenced  objects.  The  dynamic  class  is  the  one  named  in  the  new 
expression  where  each  object  is  created.  Static  classes  of  a  given  object  differ  at  different 
program  points;  dynamic  classes  are  unchanging.  Static  classes  are  known  at  compile¬ 
time;  dynamic  classes  are  revealed  at  run-time  only  by  reflection  and  dynamic  casts. 

We  can  implement  precisely  this  distinction  in  Mini  JFlint.  Essentially,  some  prefix 
of  the  object  record— corresponding  to  the  static  class— is  known,  while  the  rest  of  the 
record  is  hidden.  As  we  have  seen,  rows  allow  one  to  name  the  suffixes  of  records,  and 
existential  types  are  useful  for  data  hiding.  Consider  this  static  type  of  a  Point  object;  it 
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uses  a  pair  of  existentially-quantified  rows. 

rpt  =  3tail::{f ::  R{vtab,xl,  m ::  Type=>R'getx! }. 

pself.  {vtab:  {getx:self^int;tail-m  self} ; x :  int ; tail -f} 

The  f  component  of  the  tail  tuple  denotes  a  hidden  row  missing  the  labels  vtab  and  x. 
Subclasses  of  Point  append  new  fields  by  packaging  non-empty  rows  into  the  witness 
type.  Similarly,  tail  contains  a  component  m  for  appending  new  methods  onto  the  vtable. 
In  this  case,  the  hidden  component  is  a  type  function  expecting  the  recursive  self  type, 
so  that  it  can  be  propagated  to  method  types  in  the  dynamic  class,  further  down  the 
hierarchy. 

Now,  we  can  disguise  objects  of  sub-classes  to  look  like  objects  of  any  super  class. 
The  Point  object  pi  is  packaged  into  a  term  of  type  r'pL  using  the  trivial  witness  type 

{f  =  Abs{vtab’x} ,  m  =  As::Type.  Abs {getx} } 

To  package  an  object  of  dynamic  class  ScaledPoint  into  type  r'pt  we  hide  a  non-trivial 
witness  type,  containing  the  new  field  and  method: 

{f  =  (s  :  int;Abs{vtab’x’s}), 
m  =  Aself::Type.  (gets :  self— int ;  Abs{getx’gets} )} 

A  packaged  object  can  also  be  repackaged  to  match  the  static  type  of  some  super  class— 
this  is  simply  an  upward  cast.  The  code  in  figure [5d~1on  the  facing  page  explicitly  casts  q 
from  Point  to  Object.  Establishing  the  typing  derivation  (using  the  rules  from  chapter[4) 
is  a  good  way  to  understand  this  code. 

This  is,  in  essence,  the  object  encoding  we  use  to  compile  Java.  Before  embarking  on 
the  formal  translation,  we  must  explore  one  more  aspect:  recursive  references.  Suppose 


5.1.  SELF  APPLICATION 


57 


q0  =  open  q  as  (tai I:: {f ::  R*vtab,x*,  m  ::Type^R!getx!},  obj :. . .) 
in  (tair::{f ::  R{vtab|,  m  ::Type=>R0}  = 

{f  =  (x :  int ; tail -f) ,  m  =  As::Type.  (getx:  s  —  int;  tail-m  s) }, 
obj : pself::Type.  {vtab :  {tail'  -m  self};  tail'-f}) 

Figure  5.1:  Casting  q  from  Point  to  Object 

the  Point  class  has  also  a  method  bump  which  returns  a  new  Point.  The  type  of  objects  of 
class  Point  must  then  refer  to  the  type  of  objects  of  class  Point.  This  recursive  reference 
calls  for  another  fixed  point,  outside  the  existential: 

jUtwin.  Btail.  juself.  {vtab:  {getx:self^int;bump:self^twin;tail-m  self}; 
x:int;  tai  I  ■  f } 

Using  self  as  the  return  type  would  overly  constrain  implementations  of  bump,  forcing 
them  to  return  objects  of  the  same  dynamic  class  as  the  receiver.  In  Java,  type  signatures 
constrain  static  classes  only.  Because  twin  is  outside  the  existential,  its  witness  type  can 
be  distinct  from  that  of  self. 

This  technique  explains  self-references,  but  Java  supports  mutually  recursive  refer¬ 
ences  as  well.  Suppose  class  A  defines  a  method  returning  an  object  of  class  B,  and  vice 
versa;  ignoring  fields  entirely  for  a  moment,  define  the  following  type: 

AB  =  pw::{A::Type,  B::Type}. 

{A=  3tail::Type^Rigetb| . pself::Type.  {getb:self^w-B;tail  self}, 

B  =  3tail::Type=>R!getal.pself::Type.  {geta:self^w-A;tail  self}} 

Using  the  contextual  fold  and  unfold  described  earlier,  objects  of  class  A  can  be  folded 
into  the  type  AB- A.  This  is  the  natural  generalization  of  the  twin  fixed  point.  In  the  most 
general  case,  any  class  can  refer  to  any  other,  so  w  must  expand  to  include  all  classes; 
this  is  the  technique  we  use  in  the  formal  translation.  In  an  actual  compiler,  we  would 
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fieldvec (Object)  =  [(vtab,  vt)]  (5.1) 


CT{ C)  =  class  C  extends  B  {  Di  fi ; . . .  Dm  fm;  K. . .  } 

fieldvec  {C)  =  fieldvec  {B)  ++  [(fi,  Di) ...  (fm,  Dm)] 


me  thvec(  Object)  =  [(dyncast.dc)]  (5.3) 


CT{ C)  =  class  C  extends  B  {  . . .  K  Mi . . .  Mm  } 

methvec(C)  =  methvec{B)  ++  addmeth{B,  [Mi . . .  Mm]) 


(m, _)  e  methvec(B) 

addmeth{B,  [D  m  (Di  xi . . .  Dfc  x^)  {  return  e;  }  M2  . . .  Mm])  =  (5.5) 

addmeth(B,  [M2  . . .  Mm]) 


(m, _)  ^  methvec(B) 

addmeth{B,  [D  m  (Di  xi . . .  x^)  {  return  e;  }  M2  . . .  Mm])  =  (5.6) 

[(m,  Di . . .  Dfc  —  D)]  ++  addmeth(B,  [M2  . . .  Mm]) 


addmeth{B,  [])  =  []  (5.7) 

Figure  5.2:  Field  and  method  layouts  for  object  types 

analyze  the  reference  graph  and  cluster  the  strongly-connected  classes  only.  Note  that 
this  only  addresses  the  typing  aspect;  mutual  recursion  has  term-level  implications 
also— any  class  can  cast  to  or  construct  objects  of  any  other;  see  section [5^4 

5.2  Type  translation 

This  completes  our  informal  account  of  self  application;  we  now  turn  to  a  formal  trans¬ 
lation  of  FJ  types.  Figure  [572] defines  several  functions  which  govern  the  layout  of  fields 
and  methods  in  object  types.  Square  brackets  [■]  denote  sequences.  The  sequence 
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si  ++52  is  the  concatenation  of  sequences  S\  and  52-  |s|  denotes  the  number  of  ele¬ 
ments  in  s.  The  domain  of  a  sequence  of  pairs,  domU),  is  a  set  consisting  of  the  first 
elements  of  each  pair  in  s. 

The  function  fieldvec  maps  a  class  name  C  to  a  sequence  of  tuples  of  the  form  (f,  D), 
indicating  a  field  of  type  D  named  f— except  for  the  first  tuple  in  the  sequence,  which  is 
always  (vtab,  v  t),  a  placeholder  for  the  vtable.  Each  class  simply  appends  its  own  fields 
onto  the  sequence  of  fields  from  its  super  class.  (In  FJ,  the  fields  of  a  class  are  assumed 
to  be  distinct  from  those  of  its  super  classes.) 

The  layout  of  methods  in  an  object  type  is  somewhat  trickier.  Methods  that  appear  in 
a  class  definition  are  either  new  or  they  override  methods  in  the  super  class.  Overriding 
methods  do  not  deserve  a  new  slot  in  the  vtable.  The  function  methvec  maps  a  class 
name  C  to  a  sequence  of  tuples  of  the  form  (m,  T),  indicating  a  method  named  m  with 
signature  T.  Signatures  have  the  form  Di . . .  Dn  —  D.  The  function  addmeth  iterates 
through  all  the  methods  defined  in  the  class  C,  adding  only  those  methods  that  are  new 
(not  just  overridden).  The  first  tuple  in  methvec  is  always  (dyncast,  dc),  a  placeholder 
for  the  special  polymorphic  method  used  to  implement  dynamic  casts. 

Let  cn  denote  the  set  of  class  names  (including  Object)  in  some  program  of  interest. 
For  the  purpose  of  presentation,  we  abbreviate  the  kind  of  a  tuple  of  all  object  types  as 
ken.  The  tuple  of  row  kinds  for  class  C  is  abbreviated  ktail[C]. 

ken  =  {(E::Type) Eec”} 

ktail[C]  =  {m  ■■  Type^Rdom(mef?,vec(C^  f  ■■  Rdom(/ieZdvec(C))  j 

For  brevity,  we  sometimes  omit  kind  annotations.  By  convention,  certain  named  type 
variables  are  bound  by  particular  kinds— w  has  kind  ken,  self  and  u  have  kind  Type, 
and  tail  has  kind  ktail[C],  where  C  should  be  evident  from  the  context.  This  is  just  a 
convention  of  notation,  and  does  not  imply  that  the  names  of  type  variable  are  special. 
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Rows[C,C]  =  Aw.'.kcn.  Au::Type.  Atail::kfaz7[C].  tail 


(5.8) 


7?ows[Object,  T ]  =  Aw::kcn.  Au::Type.  Atail::kfaz7[Object]. 

{m  =  Aself::Type.  (dyncast:self— Va::Type.  (u  — maybe  a)  — maybe  a; 
tail-m  self) 

f  =  tail  ■  f} 


CT (C)  =  class  C  extends  B  {  Di  fi . . .  Dn  fn  K  Mi . . .  Mm  } 

Rows[  B,A]  =  t  addmethjB,  [Mj...Mm])  =  [(h,  TQ  . . .  {lm,  Tm)] 
7?ows[C,A]  =  Aw.'.kcn.  Au::Type.  Atail::kfaz7[C]. 
t  w  u  {m  =  Aself::Type.  (l\ :  Ty [self; w;  T\] ;  Ty [self; w;  Tm] ; 

tail-m  self), 

f  =  (f i :  w ■  Di ; . . .  fn :  w  ■  Dn ;  tai I  ■  f ) } 


7y[self;  w;  Di . . .  Dn  — •  D]  =  self— w-Di—  . . .  w-Dn— w-D 


(5.11) 


Figure  5.3:  Definition  of  rows 


EmptyLC]  =  {m  =  Aself::Type.  Absdom(mef?7vec(C)),  f  =  Absdom(^eWvec(C))} 

ObjRcd[ C]  =  \w::kcn.  Au::Type.  Atail::fefaz7[C].  Aself::Type. 

{vtab :  {(i?ows[C,  t]  w  u  tail)  -m  self} ;  (i?ows[C,  t]  w  u  tail)  -f } 
Se//Ty[C]  =  Aw::/ccn.  Au::Type.  Atail::kfaz7[C].  ji/self::Type.  ObjRcd[ C]  w  u  tail  self 
ObjTy[C]  =  Aw.-.kcn.  Au::Type.  3tail::kfaz7[C].  5e//Ty[C]  wu  tail 
World  =  Au::Type. /tw::kcu.  {(E  =  ObjTy[E]  w  u)  Eecn  } 

Figure  5.4:  Macros  for  object  types 


In  figure [573]  we  define  Rows,  a  type  operator  that  produces  rows  containing  the  fields 
and  methods  introduced  between  two  classes  in  a  subclass  relationship.  Intuitively, 
f?ows[C,  A]  includes  fields  and  methods  in  class  C  but  not  in  its  ancestor  class  A.  Earlier 
we  described  how  to  package  dynamic  classes  into  static  classes;  the  witness  type  was 
a  tuple  of  rows  containing  the  fields  and  methods  in  the  dynamic  class  but  not  in  the 
static  class.  This  is  just  one  use  of  the  Rows  operator. 

The  type  operator  l?ow5[C,  A]  has  kind  kcn=»Type=>kfuz7[C]=>kfuz7[A];  recall  that  => 
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is  the  kind-level  arrow  in  Mini  JFlint.  The  operator’s  first  argument,  w wkcn,  is  a  tuple 
containing  object  types  for  all  classes  in  the  compilation  unit.  The  next  argument, 
u::Type,  is  a  universal  type  used  to  implement  dynamic  casts.  This  will  be  explained  in 
section  [5~4]  for  now,  we  only  observe  that  the  definitions  in  figure [P] simply  propagate 
u  so  that  it  can  appear  in  the  type  of  the  dyncast  pseudo-method.  The  final  argument, 
tail::ktaz'/[C],  contains  the  rows  for  some  subclass  of  C. 

f?ows[C,  A]  is  defined  by  three  cases.  First,  if  C  and  A  are  the  same  class,  then  the 
result  is  just  the  tail— those  members  in  subclasses  of  C.  Second,  if  C  is  Object  (the  root 
of  the  class  hierarchy)  and  A  is  the  special  symbol  T  then  the  result  is  the  members 
declared  in  Object.  Treating  T  as  the  trivial  super  class  of  Object  permits  more  uniform 
specifications  (since  Object  contains  members  of  its  own).  Finally,  in  the  inductive  case 
(where  C  <:A)  we  look  to  C’s  super  class— let’s  call  it  B.  7?ows[B,  A]  produces  a  type 
operator  for  the  members  between  B  and  A;  we  need  only  append  the  new  members  of  C. 
Conveniently,  f?ows[B,  A]  has  a  tail  parameter  specifically  for  appending  new  members. 
The  formal  definition  of  Rows  is  in  figure  |5.3| 

The  new  fields  in  C  are  precisely  those  listed  in  the  declaration  of  C;  we  fetch  their 
types  from  w  and  append  tail  - f.  The  new  methods  in  C  are  found  using  addmeth,  and 
their  type  signatures  Di ...  D„  —  Dare  translated  to  arrow  types:  self^  w-Di— . . .  w-D„.^ 
w-D.  We  use  curried  arguments  for  convenience;  an  actual  implementation  would  use 
multi-argument  functions  instead.  As  shown  in  the  informal  examples,  the  row  for 
methods  is  parameterized  by  the  type  of  self.  As  a  concrete  example,  the  rows  for  Point 
and  ScaledPoint  are  in  figure [53] on  the  next  page. 


In  figure  |5.4|  we  use  the  Rows  operator  to  define  macros  for  several  variants  of 
the  object  type  for  any  given  class.  Empty[C]  denotes  the  tuple  of  empty  field  and 
method  rows  of  kind  ktail[C].  ObjRcd[ C]  assembles  the  rows  into  records,  leaving  the 
subclass  rows  and  self  type  open.  SelfTy[C]  closes  self  with  a  fixed  point,  and  ObjTy\C] 
hides  the  sublass  rows  with  an  existential.  Each  of  these  variants  is  used  in  our  term 
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Rows[P,  Object]  =  Aw.  Au.  Atail.  {m  =  Aself.  (getx  :  self^int ;  tail-m  self), 

f  =  (x:  int ;  tail -f)} 

Rows [SP,  P]  =  Aw.  Au.  Atail.  {m  =  Aself.  (gets  :  self^ int ;  tail  -m  self), 

f  =  (s  :  int ;  tail ■  f) } 

Rows[SP,  Object]  =  Aw.  Au.  Atail.  Rows[P,  Object]  w  {Rows[SP,  P]  wtail) 

=  Aw.  Au.  Atail.  {m  =  Aself.  (getx  :  self^int ; 

gets  : self^ int; tail -m  self), 
f  =  (x :  int ;  s :  int ;  tail-f)} 


Figure  5.5:  Rows  for  Point  and  ScaledPoint 


pack[C;  u;tail;e]  = 

fold  (tail'::ktaz7[C]  =  tail,  e:SelfTy[C\  ( World  u)  u  tail') 
as  World  u  at  \y::kcn.y-C 


upcast[C;  A;  u;e]  = 

open  (unfold  e  as  World  u  at  Xyv.kcn.  y -C) 
as  (tail::ktaz7[C],  x:5e//Ty[C]  ( World  u)  u  tail) 
in  pack[A;  u;Rows[C,  A]  ( World  u)  u  tail;  a:] 

Figure  5.6:  Definitions  of  pack  and  upcast  transformations 


translation.  All  of  them  remain  abstracted  over  both  w  (the  types  of  other  objects)  and  u 
(the  universal  type,  which  is  simply  propagated  into  the  type  of  dyncast).  Finally,  World 
constructs  a  package  of  the  types  of  objects  of  all  classes,  given  the  universal  type  u; 
as  we  will  see  later,  the  actual  universal  type  is  a  labeled  sum  of  object  types,  and  is 
defined  recursively  using  World. 


5.3  Expression  translation 


Equipped  with  an  efficient  object  encoding  and  several  type  operators  for  describ¬ 
ing  it,  we  now  examine  the  type-directed  translation  of  FJ  expressions.  Figures  |5.6| 


and  5.7  contain  definitions  of  pack  and  upcast,  and  six  rules  governing  the  judgment 


EXP[r;  u;  classes;  e]  =  e  for  term  translation.  Here,  r  is  the  FJ  type  environment,  u  is  the 
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EXP[r;  u;  classes;  x]  =  x 


(5.12) 


(f,  _)  6  fieldvec(C)  ri-eeC  exp|T;  u;  classes;  e]  =  e 
EXP[r;  u;  classes;  e.f]  = 

open  (unfold  e  as  World  u  at  A ywkcn.  y  ■  C)  (5.13) 

as  (tail::feffli7[C],  x  :SelfTy[C]  ( World  u)  u  tail) 

in  (unfold  x).f 


r  t-  e  6  C  (m,  Bi . . .  Bn  —  B)  e  methvec(C)  EXP[r;  u;  classes;  e]  =  e 
T  H  e,  e  D,  Dj  <:  B, 

upcast[D,;B,;u;exp|T;u;  classes;  e,]]  =  eu  ie  {l..n} 

EXP[r;  u;classes;  e.m  (ei . .. en)]  =  (5.14) 

open  (unfold  e  as  World  u  at  Xyw.kcn.  y -C) 
as  (tail::fcfaz'Z[C],  x\SelfTy[C]  ( World  u)  u  tail) 

in  (unfold  x).vtab.m  x  e\  ...  en 


fields (C)  =  Bi  fi . . .  Bn  fn 
r  H  e,  e  Dj  Dj  <:  B, 

UPCAST[D,;B,;u;EXP[r;u; classes; e,]]  =  eit  ie  {l..n} 

EXP[r;  u;  classes;  new  C  (ei  ...e„)]  =  (classes. C  {}).newei  ...  en 


(5.15) 


ri-eeD  D<:C 

EXP[f;  u;  classes;  (C)  e]  =  upcast[D;  C;  u;exp[T;  u;  classes;  e]] 


(5.16) 


T  h  e  £  C  D<:C  EXP[r;  u;  classes;  e]  =  e 
EXP[r;  u;  classes;  (D)  e]  = 
open  (unfold  e  as  World  u  at  Xywkcn.  y -C) 
as  (tail::fctaz7[C],  x:SelfTy[C]  ( World  u)  u  tail) 
in  case  (unfold  x).vtab.dyncast  x  [(World  u)-D]  (classes. D  { } ) . p roj 
of  some  y  =>  y  else  abort  [(World  u)  -D] 


Figure  5.7:  Type-directed  translation  of  FJ  expressions 
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universal  sum  type,  classes  is  a  record  containing  the  runtime  representations  of  each 
class,  e  is  an  FJ  expression,  and  e  is  its  corresponding  term  in  the  target  language.  If  e 
has  type  C,  then  its  translation  e  has  type  ( World  u)-C  (see  theorem[|]in  section[T8). 

The  pack  operation  packages  and  folds  a  recursive  record  term  into  a  closed,  com¬ 
plete  object  whose  type  is  selected  from  a  mutual  fixed  point  of  the  types  of  objects  of 
all  classes.  Suppose  that  tail  is  some  row  tuple  in  ktail[C]  and  e  has  type: 


Se//Ty[C]  ( World  u)  u  tail 


Then,  the  term  pack[C;  u;  tail;  e]  has  type  ( World  u)  -C.  Since  unpacking  an  object  binds 
a  type  variable  to  the  hidden  witness  type,  it  is  not  as  convenient  to  define  as  a  macro, 
and  we  perform  it  inline  instead. 

The  upcast  operation  opens  a  term  representing  an  object  of  class  C  and  repackages 
it  as  a  term  representing  an  object  of  some  super  class  A.  The  object  term  e  has  type 
{World  u)  -  C  where  C  <:  A,  but  dynamically  it  might  belong  to  some  subclass  D  <:  C.  The 
open  binds  the  type  variable  tail  to  the  hidden  row  types  that  represent  members  in  D 
but  not  in  C.  The  upcast  macro  then  uses  Rows  to  prefix  tail  with  the  types  of  members 
in  C  but  not  in  A.  Finally,  upcast  uses  pack  to  hide  the  new  tail,  yielding  an  object  term 
of  type  ( World  u)  -  A. 

These  definitions  simply  and  effectively  formalize  the  encoding  techniques  demon¬ 
strated  in  the  previous  section.  Importantly,  they  use  type  manipulations  only  (fold, 
unfold,  open).  Since  these  operations  are  erased  before  runtime,  the  pack  and  upcast 
transformations  have  no  impact  on  performance. 

We  now  explain  each  of  the  translation  rules  in  figure  |5.7[  beginning  with  (|5.12). 
Variables  in  FJ  are  bound  as  method  arguments.  Methods  are  translated  as  curried 
abstractions  binding  the  same  variable  names.  Therefore,  variable  translation  (|5.12)  is 
trivial.  An  upcast  expression  (C)  e  (where  Ti-eeD  and  D  <:  C)  is  also  trivial;  the  rule 
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(|5.16|  delegates  its  task  to  the  macro  of  the  same  name. 

The  field  selection  expression  e.f  translates  to  an  unfold-open-unfold-select  idiom  in 
the  target  language  (|5.13|.  In  this  sequence,  the  select  alone  has  runtime  effect.  Method 
invocation  e.m  (ei . . .  en)  augments  the  idiom  with  applications  to  self  and  the  other  ar¬ 
guments,  but  there  is  one  complication.  The  FJ  typing  rule  permits  the  actual  arguments 
to  have  types  that  are  subclasses  of  the  types  in  the  method  signature.  Since  our  encod¬ 
ing  does  not  utilize  subtyping,  the  function  selected  from  the  vtable  expects  arguments 
of  precisely  the  types  in  the  method  signature.  Therefore,  we  must  explicitly  upcast  all 
arguments.  Rule  (|5. 14[>  formalizes  the  self-application  technique  demonstrated  earlier. 

The  code  to  create  a  new  object  of  class  C  essentially  selects  and  applies  C’s  con¬ 
structor  from  the  classes  record.  Until  we  explain  class  encoding  and  linking,  the  type 
of  classes  will  be  difficult  to  justify.  Presently  it  will  suffice  to  say  that  classes. C  applied 
to  the  unit  value  {}  returns  a  record  which  contains  a  field  new— the  constructor  for 
class  C.  The  translation  j5.15)  upcasts  all  the  arguments,  then  fetches  and  applies  the 
constructor. 

The  final  case,  dynamic  casts,  may  appear  quite  magical  until  we  reveal  the  imple¬ 
mentation  of  the  dyncast  pseudo-method  in  the  next  section.  For  now  it  is  enough  to 
treat  dyncast  as  a  function  of  type  self^  Va.  (u  —  maybe  a)  —  maybe  a,  where  self  is  the 
type  of  the  unfolded  unpacked  object  bound  to  x.  The  argument  of 


(unfold  xj.vtab. dyncast  x  [r] 


is  a  projection  function,  attempting  to  convert  a  value  of  type  u  to  an  object  of  type 
r.  The  record  classes. C  {}  contains,  in  addition  to  the  field  new,  a  proj  field  of  type 
u  — maybe  {(World  u )  - C) .  Thus  if  we  select  the  dyncast  method  from  an  object,  instan¬ 
tiate  it  with  the  object  type  for  some  class  C,  then  pass  it  the  projection  for  class  C, 
it  will  return  some  C  object  if  the  cast  succeeds,  or  none  if  it  fails.  In  case  of  failure, 
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evaluation  aborts.  In  full  Java,  we  would  throw  a  ClassCast  exception. 

Note  that  Featherweight  Java’s  stupid  casts  (Igarashi,  Pierce,  and  Wadler  2001)  are 
not  compiled  at  all.  They  arise  in  intermediate  results  during  evaluation,  but  should 
not  appear  in  valid  source-level  programs. 

The  expression  translation  judgment  exp  preserves  types.  Informally,  if  e  has  type 
C,  then  its  translation  has  type  ( World  u)-C,  for  some  type  u.  The  type  preservation 


theorem  is  stated  formally  and  proved  in  section  5.8 


5.4  Class  encoding 

Apart  from  defining  types,  classes  in  FJ  serve  three  other  roles:  they  are  extended, 
invoked  to  create  new  objects,  and  specified  as  targets  of  dynamic  casts.  In  our  trans¬ 
lation,  each  class  declaration  is  separately  compiled  into  a  module  exporting  a  record 
with  three  elements— one  to  address  each  of  these  roles.  We  informally  explain  our 
techniques  for  implementing  inheritance,  constructors,  and  dynamic  casts,  then  give 
the  formal  translation  of  class  declarations. 

In  a  class-based  language,  each  vtable  is  constructed  once  and  shared  among  all 
objects  of  the  same  class.  In  addition,  the  code  of  each  inherited  method  should  be 
shared  by  all  inheritors.  How  might  we  implement  the  Point  methods  so  that  they  can 
be  packaged  with  a  ScaledPoint?  We  make  the  method  record  polymorphic  over  the  tail 
of  the  self  type: 

dictPT  =  Atail::kfflz'Z[PT].  {getx  =  Aself  :spt.  (unfold  self) .x} 
where  spt  =  pa.  {vtab :  {getx :  a— int ;  tai I  -  m  «} ;  x :  int ;  tail  - f} 

We  call  this  polymorphic  record  a  dictionary.  By  instantiating  it  with  different  tails,  we 
can  directly  package  its  contents  into  objects  of  subclasses.  Instantiated  with  empty 
tails  (Empty[ PT],  for  example),  this  dictionary  becomes  a  vtable  for  class  Point.  Suppose 
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Dict[C ]  =  Aw::kcn.  Au::Type.  Aself::Type.  {(7?ow,s[C,  t]  w  u  Empty[C])- m  self} 

Ctor[C]  =  Aw::/ccn.  w-Di—  . . .  w-D^w-C 
where  fields(C)  =  Di  fi . . .  Dn  fn 
Proj[ C]  =  Aw::kcn.  Au::Type.  u  — maybe  w-C 

Inj[C ]  =  Aw::kcn.  Au::Type.  w-C^u 

C/fl55[C]  =  Aw::/ccn.  Au::Type.  {diet :  Vtail::kfaz7[C].Dzcf[C]  w  u  (5e//Ty[C]  w  u  tail), 

proj  :Proj[C]  w  u,  new:  Cfor[C]  w } 

Classes  =  Awr.kcn.  Au::Type.  ( ( E :  1  —  C/czs.s[E]  w  u  ; )  Eecn  Absc”) 

ClassF[C ]  =  Vu::Type.7zij[C]  ( World  u)  u — Proj [ C ]  ( World  u) 

{Classes  ( World  u)  u}^l  —  Class \ C  |  ( World  u)  u 

Figure  5.8:  Macros  for  dictionary,  constructor,  and  class  types 

the  ScaledPoint  subclass  inherits  getx  and  adds  a  method  of  its  own.  Its  dictionary 
would  be: 

dictSP  =  Atail::A:taz7[SP].  {getx  =  (dictPT  [r5f7]).getx, 

gets  =  Aself  :sSp.  (unfold  s e I f ) . s } 
where  rsp  =  7?ows[SP,  PT]  ( World  u)  u  Empty  [SP] 

and  ssp  =  pa.  {vtab:  {getx:a—int;gets:a— int;tail-m  cx} ; 
x :  int ;  s :  int ;  tail  ■  f} 

This  dictionary  can  be  instantiated  with  empty  tails  to  produce  the  ScaledPoint  vtable. 
With  other  instantiations,  further  subclasses  can  inherit  either  of  these  methods.  The 
dictionary  is  labeled  diet  in  the  record  exported  by  the  class  translation. 

Constructors  in  FJ  are  quite  simple;  they  take  all  the  fields  as  arguments  in  the  correct 
order.  Fields  declared  in  the  super  class  are  immediately  passed  to  the  super  initializer. 
We  translate  the  constructor  as  a  function  which  takes  the  fields  as  curried  arguments, 
places  them  directly  into  a  record  with  the  vtable,  and  then  folds  and  packages  the 
object.  The  constructor  function  is  labeled  new  in  the  class  record.  In  section  [6]  we 
describe  how  to  implement  more  realistic  constructors. 
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Implementing  dynamic  cast  in  a  strongly-typed  language  is  challenging.  Somehow 
we  must  determine  whether  an  arbitrary,  abstractly-typed  object  belongs  to  a  particular 
class.  If  it  does  belong,  we  must  somehow  refine  its  type  to  reflect  this  new  information. 
Exception  matching  in  SML  poses  a  similar  problem.  To  address  these  issues,  Harper  and 
Stone  |1998)  introduce  tups— values  which  track  type  information  at  runtime.  If  a  tag  of 
abstract  type  Tag  a  equals  another  tag  of  known  type  Tag  r,  then  we  update  the  context 
to  reflect  that  a  =  r.  Note  that  this  differs  from  intensional  type  analysis  ([Harper  and] 
Morrisett  1995),  which  performs  structural  comparison  and  does  not  distinguish  named 
types. 

Tags  work  well  with  our  encoding;  in  an  implementation  that  supports  assignment 
and  an  SML  front-end,  it  may  be  a  good  choice.  In  this  formal  presentation,  however, 
type  refinement  complicates  the  soundness  proof  and  the  imperative  nature  of  maketag 
constrains  the  operational  semantics,  which  is  otherwise  free  of  side  effects,  maketag 
implements  a  dynamically  extensible  sum,  which  is  needed  for  SML  exceptions,  but  is 
overkill  for  classes  in  L J. 

We  propose  a  simpler  approach,  which  co-opts  the  dynamic  dispatch  mechanism. 
The  vtable  itself  provides  a  kind  of  runtime  class  information.  A  designated  method, 
if  overridden  in  every  class,  could  return  the  receiver  at  its  dynamic  class  or  any  super 
class.  We  just  need  a  runtime  representation  of  the  target  class  of  the  cast,  and  some 
way  to  connect  that  representation  to  the  corresponding  object  type,  for  this,  we  can 
use  the  standard  sum  type  and  a  ‘one-armed’  case.  Let  u  be  a  sum  type  with  a  variant 
for  each  class  in  the  class  table.  The  function 


Ax  :u.  case  x  of  C  y  =>  some  [ObjTy[C]  ( World  u)  u ]  y 
else  none  [ObjTy[C]  ( World  u)  u] 


could  dynamically  represent  class  C.  To  connect  it  to  the  object  type,  we  make  the 
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dyncast  method  polymorphic,  with  the  type 

self^Vcv.  (u  —  maybe  a)  —  maybe  a 

This  method  can  check  its  own  class  against  the  target  class  by  injecting  self  and  apply¬ 
ing  the  function  argument.  If  the  result  is  none,  then  it  tries  again  by  injecting  as  the 
super  class,  and  so  on  up  the  hierarchy. 

With  this  solution,  we  must  be  careful  to  preserve  separate  compilation— the  univer¬ 
sal  type  u  includes  a  variant  for  every  class  in  the  program.  Fortunately,  in  a  particular 
class  declaration  we  need  only  inject  objects  of  that  class.  Class  declarations  can  treat 
u  as  an  abstract  type  and  take  the  injection  function  as  an  argument.  Then  only  the 
linker  needs  to  know  the  concrete  u  type. 


5.5  Class  translation 


We  now  explore  the  formal  translation  of  class  declarations  and  construction  of  their 
method  dictionaries.  In  figure  [578]  we  define  several  macros  for  describing  dictionary 
and  class  types.  Figure  [T9] on  the  following  page  gives  translations  for  each  component 
of  the  class  declaration. 

Each  class  is  separately  compiled  to  code  that  resembles  an  SML  functor— a  set  of 
definitions  parameterized  by  both  types  and  terms.  Linking— the  process  of  instanti¬ 
ating  the  separate  functors  and  combining  them  into  single  coherent  program— will  be 


addressed  in  the  next  section.  Our  compilation  model  is  the  subject  of  section  5.7 


cdec [C]  produces  the  functor  corresponding  to  class  C;  see  the  definition  at  the  top 
of  figure  [T9]  The  code  has  one  type  parameter:  u,  the  universal  type  used  for  dynamic 
casts.  Following  it  are  two  function  parameters  for  injecting  and  projecting  objects  of 
class  C.  The  next  parameter  is  classes,  a  record  containing  definitions  for  other  classes 
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Class  declaration  translation: 


CDEC[C]  = 

Au::Type.  Ainj  :Inj[C]  { World  u)  u.  Aproj  :Proj[C]  { World  u)  u. 

Aclasses  :  {Classes  { World  u )  u } .  A_ :  1 . 

let  diet :  Vtail::fcfaz7[C].  Dict[C]  { World  u)  u  {SelfTy[C]  ( World  u)  u  tail) 
=  dict[C;  u;  inj;  classes] 
in  let  vtab  =  diet  [ Empty[C ]] 

in  {diet  =  diet,  proj  =  proj,  new  =  NE\v[C;  u;vtab]} 

Dictionary  construction: 


DiCT[Objeet;  u;  inj;  classes]  =  Atail::fctaz7[Object]. 
{dyncast  =  Aself :  Se//Ty[C]  ( World  u)  u  tail. 

Aa::Type.  Aproj :  u  — maybe  a. 

proj  (inj  PACK[Objeet;  u;  tail;  self])} 


CT( C)  =  class  C  extends  B  {  ...  }  dom{methvec{C))  =  [ii . . .  ln ] 
dict[C;  u;  inj;  classes]  =  Atail::fctaz7[C]. 

let  super:Dz'cf[B]  ( World  u)  u  {SelfTy[C]  {World  u)  u  tail) 

=  (classes. B  { } ) .diet  [f?ows[C,  B]  ( World  u)  u  tail] 
in  {li  =  meth[C;  Ip, u;  tail;  inj;  classes;  super], 
ln  =  meth[C;  ln\  u;  tail;  inj;  classes;  super]} 

Constructor  code: 

fields {C)  =  Pi  fi . . .  D„  fn _ 

new[C;  u;  vtab]  =  Afi :  ( World  u) -Di.  ...  Afn :  ( World  u)  -Dn. 

let  x  =  fold  {vtab  =  vtab,  fi  =  fi, . . .  ,fn  =  fn} 
as  SelfTy[C]  {World  u)  u  Empty[C ] 
in  pack[C;  u; Empty[C]; x] 


(5.18) 


(5.19) 


(5.20) 


(5.21) 


Figure  5.9:  Translation  of  class  declarations 
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Method  code: 

meth[C;  dyncast;  u;  tail;  inj;  classes;  super]  = 

Aself :  5e//Ty[C]  ( World  u)  u  tail.  Aa::Type.  Aproj :  u^  maybe  a. 
case  proj  (inj  pack[C;  u; tail;  self]) 

of  some  x  =>  some  [«]  x  else  super. dyncast  self  [«]  proj 


(5.22) 


CT{ C)  =  class  C  extends  B  {  . . .  I<  Mi . . .  Mn  } 

m  not  defined  in  Mi ...  M„  (5.23) 

meth[C;  m;  u;  tail;  inj;  classes;  super]  =  super.m 


CT{ C)  =  class  C  extends  B  {  . . .  K  Mi . . .  Mn  } 

3j  :  Mj  =  A  m  (Ai  xi . . .  Am  xm)  {  return  e;  } 
r  =  Xi:Ai,...,xm:Am,this:C  Tl-eeD  D<:A 
EXP[r;u;classes;e]  =  e 

meth[C;  m;  u;  tail;  inj;  classes;  super]  =  (5.24) 

Aself:  Se//Ty[C]  (1 World  u)  u  tail. 

Axi :  ( World  u)  -Ai.  . . .  Axm  :  ( World  u)  ■ Am . 
let  this :  ( World  u)  C  =  pack[C;  u;  tail;  self] 
in  upcast [D;  A;  u;e] 

Figure  5.10:  Translation  of  method  declarations 


that  are  mutually  recursive  with  C  (for  convenience,  we  assume  that  each  class  refers  to 
all  the  others).  The  final  parameter  is  of  unit  type;  it  simply  delays  references  to  classes 
so  that  linking  terminates. 

In  the  functor  body,  we  define  diet  (using  the  macro  dict)  and  vtab  (the  trivial  instan¬ 
tiation  of  dict).  dict  is  placed  in  the  class  record  (so  subclasses  can  inherit  its  methods); 
vtab  is  passed  to  the  new  macro  which  creates  the  constructor  code.  The  constructor  is 
exported  so  that  other  classes  can  create  C  objects;  and,  finally,  the  projection  function 
proj  (a  functor  parameter)  is  exported  so  other  classes  can  dynamically  cast  to  C. 

The  dictionary  for  class  Object  is  hard-coded  as  DiCT[Object; . . .  ].  It  has  a  special 
method  dyncast  that  injects  self  at  class  Object,  passes  this  to  the  proj  argument  and 
returns  the  result.  If  the  class  tags  do  not  match,  dyncast  indicates  failure  by  returning 
none;  there  is  no  super  class  to  test.  For  all  other  classes,  dict  fetches  the  super  class 
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Tagged  =Au::Type.  J(C:  ( World  u)-C)  CGcn } 

Univ  =  pu::Type.  Tagged  u 

PROG[e]  =  let  xcn  =  link  {(C  =  cdec[C])  Cec”}  in  exp[o;  Univ;xcn;e]  (5.25) 


link  =  \x:{{C:ClassF[C])CGcn}.  (5.26) 

fix  [Classes  { World  Univ)  Univ] 

(Aclasses  :  {Classes  ( World  Univ)  Univ}. 

{(C  =  x.C  [Univ]  injc  projc  classes)  Cec”}) 

where 

injc  =  Ax :  ( World  Univ)  C.  fold  inj^l,‘,‘,',l/  Unn  x  as  Univ 
projc  =  Ax :  Univ.  case  unfold  x  of  C  y  =>  some  [{World  Univ)-C]  y 

else  none  [{World  Univ)-C ] 

Figure  5.11:  Program  translation  and  linking 


dictionary  from  classes  and  instantiates  it  as  super.  It  then  uses  meth  to  construct  code 
for  each  method  label  in  methvec. 

meth  is  defined  in  figure [5TT0I on  the  page  before.  There  are  three  cases:  it  produces 
the  special  dyncast  method,  which  must  be  overridden  in  every  class  ^5.22);  it  inherits  a 
method  from  the  super  class  (|5.23|>;  or  it  constructs  a  new  method  body  by  translating 
FJ  code  (]5.24).  Note  that  the  inherited  method  has  no  overhead;  the  function  pointer  is 
simply  copied  from  the  super  class  dictionary. 


Proofs  that  the  translated  class  declarations  are  well-typed  are  in  section  5.8 


5.6  Linking 


Finally,  we  must  instantiate  and  link  the  separate  class  modules  together  into  a  single 
program.  Figure [5TTT1  gives  the  translation  for  a  complete  FJ  program  (definition|5.25). 
The  functors  that  result  from  translating  each  class  declaration  are  collected  into  a 
record  and  passed  to  the  link  function.  The  result,  bound  to  xcn,  is  a  record  of  classes. 
It  is  used  as  the  classes  parameter  in  translating  the  main  program  expression  e. 
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At  the  type  level,  we  build  the  universal  sum  ( Univ )  with  a  variant  for  the  object 
type  of  each  class  in  the  class  table.  This  type  is  propagated  into  the  translation  of  the 
main  program  expression,  and  it  is  used  to  instantiate  the  functor  corresponding  to 
each  class.  Unfolded,  it  is  written  as  Tagged  Univ. 

link  uses  fix  to  create  a  fixed  point  of  the  record  of  classes.  Each  class  functor  in 
the  argument  x  has  one  type  parameter  and  three  value  parameters.  For  each  class, 
we  define  injection  and  projection  functions,  injc  and  projc.  The  former  tags  an  object 
and  folds  to  create  a  value  of  type  Univ.  The  latter  unfolds  and  removes  the  tag,  where 
applicable.  We  define  these  functions,  and  the  sum  type  itself,  at  the  outer  level  so  that 
classes  can  be  compiled  separately,  and  yet  still  use  the  universal  sum  type  to  implement 
dynamic  cast.  The  final  argument  to  x.C  is  the  classes  record  itself.  Section [5.8.5| on 
page [83] includes  a  theorem  that  linkage  is  well-typed. 


5.7  Separate  compilation 

Our  translation  supports  separate  compilation,  but  the  formal  presentation  does  not 
make  this  clear.  In  this  section,  we  describe  our  compilation  model  and  justify  that 
claim. 

What  must  be  known  to  compile  a  Java  class  C  to  native  code?  At  a  minimum,  we 
must  know  the  fields  and  methods  of  all  super  classes,  to  ensure  that  the  layout  of 
C’s  vtable  and  objects  are  consistent.  Next,  it  is  helpful  to  know  enough  about  classes 
referenced  by  C  so  that  the  offsets  of  their  fields  and  methods  can  be  embedded  in 
the  code.  These  principles  do  not  mean  that  all  referenced  classes  must  be  compiled 
together.  Indeed,  as  long  as  the  above  information  is  known,  classes  can  be  compiled 
separately,  in  any  order. 

In  our  translation,  we  need  not  just  offsets  but  the  full  type  information  for  super 
classes  and  referenced  classes.  If  C  refers  to  field  x  from  class  D,  we  need  to  know  all 
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about  the  type  of  x  as  well.  This  clearly  involves  extracting  type  information  from  more 
classes,  although  not  necessarily  every  class  in  the  program.  Even  so,  each  class  can 
still  be  compiled  separately,  in  any  order,  assuming  the  requisite  types  are  available. 

A  reasonable  compilation  strategy  starts  with  some  root  set  of  classes  and  builds  a 
dependence  graph.  For  a  given  program,  the  root  set  contains  just  the  class  with  the 
mai  n  method;  for  a  library,  it  includes  all  exported  classes.  Next,  traverse  the  graph 
bottom-up.  Compile  each  class  separately,  but  propagate  the  necessary  information 
from  C  to  all  those  classes  that  depend  on  it.  Of  course,  there  may  be  cyclic  dependen¬ 
cies,  represented  by  strongly-connected  components  (clusters)  in  the  graph.  In  these 
cases,  we  extract  type  information  from  all  members  of  the  cluster  before  compiling 
any  of  them.  Still,  each  class  in  the  cluster  is  compiled  separately. 

A  hallmark  of  whole-program  compilation  is  that  library  code  must  be  compiled 
along  with  application  code.  This  is  clearly  not  necessary  in  our  model.  Library  classes 
would  never  depend  on  application  classes,  so  they  can  be  compiled  in  advance.  The 
reason  that  our  formal  translation  uses  the  macro  World  (containing  object  types  for 
every  class  in  the  program)  is  that,  in  the  most  general  case,  every  class  in  an  FJ  program 
refers  to  every  other  class.  Thus,  our  translation  assumes  that  the  entire  program  falls 
within  one  strongly-connected  cluster.  In  practice,  World  would  include  just  the  classes 
in  the  same  cluster  as  the  class  being  compiled. 

5.8  Properties 

This  section  contains  formal  statements  and  proofs  of  several  properties  of  our  trans¬ 
lation.  The  most  important  is  theorem  [4]  on  page  [80]  it  says  that  well-typed  Feather¬ 
weight  Java  expressions  are  translated  to  well-typed  Mini  JFlint  expressions.  Its  proof 
is  straightforward  if  we  first  factor  out  and  prove  several  key  properties  as  lemmas. 

First,  in  lemma  [6]  we  establish  a  correspondence  between  the  mtype  used  in  the  FJ 
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semantics  and  the  methvec  relation  used  for  object  layout  (likewise  between  fields  and 
fieldvec ;  see  lemma  [7).  Next,  in  lemmas  |To]  and  [TTJ  we  establish  the  correspondence 
between  pairs  in  methvec / fieldvec  and  elements  in  Rows.  These  correspondences  are 
proved  by  induction  on  the  class  hierarchy.  Finally,  we  show  in  lemmas  p~3l  and  [14]  that 
the  pack  and  upcast  macros  return  expressions  of  the  expected  type.  These  can  be 
proved  by  inspection,  but  the  latter  argument  requires  a  non-trivial  coherence  property 
for  Rows  (lemma[T2lon  page|78).  Specifically,  f?ows[A,  t]  w  u  {Rows[C,  A]  w  u  tail)  must 
be  equivalent  to  f?ows[C,  t]  w  u  tail.  This  is  proved  by  induction  on  the  derivation  of 


C  <:  A. 

5.8.1  Contents  of  field/method  vectors 


Lemma  6  (Method  vector)  mtypeim,  C)  =  Di . . .  Dn  —  Do  if  and  only  if 
(m,  Di . . .  D„  —  Do)  G  methveciC) . 

Proof  By  induction  on  the  derivation  of  C  <:  Object.  In  the  base  case,  the  implication 
holds  trivially.  Otherwise,  let  CT( C)  =  class  C  extends  B  {  . . .  K  Mi . . .  Mn  }.  We 
distinguish  two  cases: 

1.  m  is  not  defined  in  Mi . . .  Mn.  (=>)  Then, 

mtypeim, C)  =  Di . . .  Dn  —  Do  =  mtypeim,  B).  Using  the  inductive  hypothesis, 

(m,  Di . . .  Dn  —  Do)  is  in  methveciB)  and  thus  it  is  also  in  methveciC).  (<=) 
addmeth(B,  [Mi . . .  Mn])  could  not  have  added  m,  so  it  must  be  that 
(m,  Di . . .  Dn  —  Do)  6  methvec(B).  Using  the  inductive  hypothesis,  mtype{m,  B)  = 
Di . . .  Dn  —  Do  and,  in  this  case,  mtypeim,  C)  =  mtypeim,  B). 

2.  3 j  such  that  M/  =  Do  m  (Di  xi . . .  D„  xn)  {  return  e;  }.  In  this  case,  mtypeim,  C)  is 
directly  defined  as  Di . . .  Dn  —  Do- 

(=>)  case  mtypeim,  B)  =  Ci . . .  Cn  —  Co  Then,  from  class  well-formedness 
we  conclude  that  C,  =  D;  for  i  e  {0 . . .  n}.  From  the  inductive  hypothesis, 
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we  find  that  (m,  C\ . . .  Cn  —  Co)  6  methvec{B).  Thus, 

(m,  Di . . .  Dn  —  Do)  G  methvec(C). 

(=>)  case  -i 3  T  such  that  mtypeim,  B)  =  T  From  the  inductive  hypothesis 
(in  the  reverse  direction),  T  such  that  (m,  T)  e  methvec{B).  Given  this, 
we  can  show  (by  induction  on  j)  that  addmeth  adds  (m,  Di . . .  Dn  —  Do)  to 
methveciC). 

(<=)  case  (m,  Ci . . .  CM  —  Co)  g  methvec(B)  Therefore,  by  definition, 
(m,Ci...Cn  —  Co)  g  methveciC).  From  class  well-formedness,  we  argue 
that  Q  =  D;  for  i  e  {0...n}. 

( <= )  case  -i3  T  such  that  (m,T)  e  methvec{B)  Then,  addmeth  and 
mtypeim,  C)  both  assign  m  the  signature  Di . . .  Dn  —  Do.  □ 

Lemma  7  (Field  vector)  If  D  f  G  fieldsi C),  then  (f,  D)  G  fieldveci C). 

Proof  By  induction  on  the  derivation  of  C  <:  Object.  □ 


5.8.2  Object  layout 

Lemma  8  (Well-kinded  rows)  If  C  <:  A,  then 
4>  I-  kows[C,A]  ::  kcn±>Type±>ktail[C]±>ktail[A], 


Proof  By  induction  on  the  derivation  of  C  <:  A.  Observe  that  I-  ken  kind  and,  for  any 
D  G  cn,  h-  ktail[D]  kind.  Then,  the  base  case  (C  =  A)  holds  trivially.  Now,  let  CT( C)  = 
class  C  extends  B  {  Di  f i ; . . .  D„  fn ;  K . . .  }  and  B  <:  A.  Using  the  inductive  hypothesis, 
kows[B,  A]  has  kind  kcn^>  Type=>  ktaz'/[B]=>  ktail\A]  in  land  environment  <F.  The  rule 


i  5.10  constructs  a  tuple  tail'  =  {m  =  . . . ,  f  =  . . .}.  Let  <F'  =  <F,  w::  ken,  u  ::Type, 


tail ::  ktail[C].  It  remains  to  be  shown  that  tail'  has  kind  ktail [ B 1  in  land  environment 
<F'.  Consider  the  f  component;  the  argument  for  m  is  similar.  Using  the  definition  of 


ktail[C]  and  the  tuple  selection  rule  (4.13  >,  4>'  f-  tail-f  ::  pidom< fieWvec(C) > _  us^ng  ^ 
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definition  of  ken  and  class  table  well-formedness,  <f>'  I-  w-Dn  ::  Type.  Finally,  the  row 


formation  rule  (4.15  assigns  kind  Rdom(/ieWvec(C))  1  to  the  row  (fn  :w-Dn  ; tail ■  f) . 
Iterate  for  each  label;  the  resulting  row  has  kind  Rdom(/i'eMwc(C))-{c,fi...fn}  whtch  js  the 
same  as  Rd°m(/jeMvec(B)).  □ 


Lemma  9  (Tail  position)  If  C  <:  B,  4>  i-  w  ::  ken,  4>  I-  tail  ::  ktaz7[C],  and 

4>  t-  self  ::  Type,  then  (Rows[C,  B]  w  u  tail)  -m  self  has  the  form  (. . .  ;tail-m  self)  and 

(7?ows[C,  B]  w  u  tail )  ■  f  has  the  form  (. . .  ; tail -f). 

Proof  By  inspection.  □ 


Lemma  10  (Method  layout)  If  h  w  ::  ken,  4>  h  tail  ::  ktail[C],  4>  i-  self  ::  Type,  and 
(m ,  T)  G  methvec(C) ,  then 

{Rows[C,  Object]  w  u  tail)-m  self  =(...;  m  :  self—  Ty  [self;  w;  T] ;  . . .  ;tail-m  self). 


Proof  By  induction  on  derivation  of  C  <:  Object,  me thvec( Object)  is  empty,  so  the 
base  case  holds  trivially.  Otherwise,  let  CT( C)  =  class  C  extends  B  {  ...  }. 


Case  (m,  T)  e  methvec{B)  Let  tail'  =  {m  =  Aself::Type.  . . .,  f  =  . . .},  as  given  in 
rule  (|5.10);  according  to  lemma[8]  this  has  kind  ktail[B].  Invoking  the  inductive 
hypothesis  (with  tail')  we  find  that 


(J?ows[B,  Object]  w  u  tail')  -m  self 
=  (...  ;  m  :  self— Ty  [self;  w;  T] ;  ...  ;tail'-m  self) 

Then,  expanding  the  definition  we  get 


(J?ows[C,  Object]  w  u  tail)  -m  self 
=  (...  ;  m  :  self—  Ty[self;  w;  T] ; . ;  tail  -  m  self) 

Case  (m,  T)  methvec{B)  Then,  m  must  be  one  of  the  names  mi . . .  mn 
enumerated  in  the  definition.  In  this  case,  the  row  tail'-m  self  will  contain  an 
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element  m  of  type  self^Ty[self;w;  T],  This  tail'  is  passed  to  Rows  [B,  Object],  but 
according  to  lemma[9]  it  will  still  appear  in  the  result.  □ 

Lemma  11  (Field  layout)  If  C  <:  Object,  $  i-  w  ::  ken,  <1>  t—  tail  ::  ktail[C],  and 
fieldveci C)  =  fieldvec( Object)  ++  [(ii,  Di) . . .  (ln,  Dn)],  then 
Rows[C,  Object]  w  u  tail  =  l\  :w-Di ;  . . .  ln  :w-D;i ; tail -f  . 

Proof  By  induction  on  the  derivation  of  C  <:  Object.  Similar  to  the  proof  of  lemma  [To] 

□ 

Lemma  12  (Rows  coherence)  If  C  <:  A,  <i>  t-  u  ::  Type,  h  w  ::  ken,  and 
$  i-  tail  ::  ktail[C],  then 

Rows[A,  Object]  w  u  (Rows[C,  A]  w  u  tail)  =  Rows[C,  Object]  w  u  tail. 

Proof  By  induction  on  the  derivation  of  C  <:  A.  The  base  case  (C  =  A)  holds  trivially. 
Now,  let  CT(C)  =  class  C  extends  B  {  ...  }  where  B  <:  A.  The  rule  for  Rows[C,  A] 
defines  a  tuple  {f  =  . . . ,  m  =  . . .}  which  we  will  call  tail'.  Specifically,  Rows[C,  A]  w  u  tail 
=  Rows[B,  A]  w  u  tail'.  Now,  using  tail'  in  the  inductive  hypothesis,  we  find  that 
Rows[A,  Object]  w  u  (Rows[B,  A]  w  u  tail')  =  Rows[ B,  Object]  w  u  tail'.  According  to  the 
definition,  Rows [B,  Object]  w  u  tail'  =  Rows[C,  Object]  w  u  tail,  where  tail'  is  the  same 
as  above.  Substituting  equals  for  equals  (twice)  yields 

Rows[A,  Object]  w  u  {Rows[C,  A]  w  u  tail)  =  Rows[C,  Object]  w  u  tail 


□ 


5.8.3  Object  transformations 

Lemma  13  (Well-typed  pack)  If  h  tail  ::  ktail[C]  and 

<L;A  t-  e:SelfTy[C ]  ( World  u)  u  tail,  then  <L;A  t-  pack[C;  u;  tail;  e] :  {World  u)-C. 
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Proof  By  inspection  of  the  definitions,  using  the  term  formation  rules  for  fold  (|4 . 3 3 [> 
and  pack  (426).  □ 

Lemma  14  (Well-typed  upcast)  If  4>;  A  i-  e  :  ( World  u)  -C  and  C  <:  A,  then 
4>;  A  b  upcast[C;  A;  u;e] :  ( World  u)-A. 


Proof  By  inspection  of  the  definitions,  using  the  term  formation  rules  for  open  (427) 
and  unfold  (434)  and  lemmas  [8]  [12]  and  [43]  Unfolding  e  produces  a  term  of  type 
ObjTy[C]  ( World  u)  u.  Opening  this  introduces  type  variable  tail ::  ktail\ C]  and  term 
variable  x :  SelfTy[C ]  ( World  u)  u  tail;  call  this  new  environment  4)';  A'.  The  body  of  the 
open  contains  a  pack  expression,  but  in  order  to  use  lemma [13]  we  must  establish  the 
following: 

1.  4)'  f-  .Rows[C,A]  ( World  u)  u  tail  ::  ktail[A],  and 

2.  4>';A' t-  x :  SelfTy[A]  ( World  u)  u  (.Rows[C,A]  ( World  u)  u  tail). 

The  first  follows  from  lemma  [8]  The  second  reduces  to 


4>'  i-  SelfTy[A]  ( World  u)  u  (f?ows[C,A]  ( World  u)  u  tail)  = 

SelfEy[C ]  ( World  u)  u  tail  ::  Type 

By  expanding  the  definition  of  SelfTy[-]  and  applying  equivalence  rules,  it  reduces 
again  to 


4>'  i-  Rows[A,  Object]  ( World  u)  u  (.Rows[C,A]  ( World  u)  u  tail)  = 
i?ow5[C, Object]  ( World  u)  u  tail  ::  ktaz7 [Object] 

which  follows  from  lemma [12]  Finally,  lemma  [13]  can  be  invoked  to  show  that  the 
result  of  the  upcast  has  type  ( World  u)  -  A.  □ 
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5.8.4  Type  preservation  for  expressions 

FJ  contexts  are  translated  to  type  environments  as  follows: 

env[u;  r, x  :  D]  =  env[u;  T], x :  {World  u)-D 
ENV[u;  o]  =  o 


Lemma  15  (Context  translation)  If  I-  u  ::  Type  and  range(T)  e  cn,  then 
i-  env[u;  T]  type  env. 

Proof  By  inspection.  □ 

Theorem  4  (Type  preservation)  If  <i>  h-  u  ::  Type,  <f>;  A  h  classes  :  { Classes  ( World  u )  u } 
and  r  h  e  e  C,  then  <F;  A,  env[u;  T]  i-  exp[T;  u;  classes;  e] :  ( World  u)  -C. 


Proof  By  induction  on  the  structure  of  e.  We  use  the  following  abbreviations:  Ar  for 
env[u;  T];  A 'T  for  A,Ar;  and  e  for  EXP[r;  u;  classes;  e]. 


Case  15.121  e  =  x  and,  from  (|3. 1 5|>,  C  =  T(x).  Thus,  Ar(x)  =  ( World  u)-C  and 
<1>;  Ap  i-  e :  ( World  u )  ■  C. 


Case  15.131  e  =  eo.f,  and  C  =  Q,  where  r  I-  eo  6  Co  and  fields( Co)  =  Ci  fi...Cn  fn. 


By  inductive  hypothesis,  <F;  Af  i-  pq  :  ( World  u)  -Co-  The  code  in  1 5.13  1  unfolds  and 


opens  eo.  Using  the  same  argument  as  in  the  proof  of  lemma  [14]  this  introduces 
the  type  variable  tail ::  ktail[Co]  and  term  variable  x :  SelfTy [Co]  ( World  u)  u  tail; 
call  this  new  environment  Af .  Unfolding  x  yields  a  term  of  type 


{vtab:  ...  ;  (.Rows [Co, Object]  ( World  u)  u  tail) -f} 

Using  lemma[7]  (f,,  Q)  e  fieldvec{Co).  Using  lemma [TT|  we  find  that  the  row 
(Rows[ Co,  Object]  ( World  u)  u  tail)  -f  contains  a  binding  f \ :  ( World  u)  -Cj.  Using 
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record  selection,  <J>;  Ap  h-  (unfoldx . . .  ).f; :  {World  u) -C,.  Exiting  the  scope  of  the 
open,  we  conclude  <F;  Ap  i-  e  :  ( World  u)  -  C,. 

Casel5.l41  e  =  eo.m  (ei . . .  en),  where  Ti-eo  e  Co,  mtype{ m,  Co)  =  Di . . .  Dn  —  C, 
r  h  ej  e  Ci,  and  C,  <:  Dj,  for  all  i  e  {1 ...  n}.  We  use  the  inductive  hypothesis  on 
eo,  and  the  same  unfold-open-unfold  argument  as  in  the  previous  case.  Selecting 
vtab  yields  a  term  of  type 

{ (Rows[C.q,  Object]  ( World  u)  u  tail)-m  (SelfTy[Q)]  ( World  u)  u  tail)}  Using 
lemma[6]  (m,  Di . . .  Dn  —  C)  e  methvec(Co).  Using  lemma  pT)]  the  above  record 
contains  a  binding 

m  :  (SelfTy [Cq]  { World  u)  u  tail)  — Ty  [self;  JTor/d  u;  Di . . .  Dn  —  C] 

=  m  :  (SelfTy [Cq]  { World  u)  u  tail)  —  (World  u)  -Di-  . . . 

{World  u)  ■  Dn  —  ( World  u )  ■  C 

Thus,  selecting  m  and  applying  it  to  x  yields  a  term  of  type 

{World  u)  -  Di  —  . . .  {World  u)  -Dn—  {World  u)  -  C 


Now,  for  each  i  in  1 ...  n,  we  use  the  inductive  hypothesis  on  e H- ,  concluding  that 


<£;  Ap  i-  Cj :  {World  u)  -Cj.  Using  this  and  C t  <:  D,,  lemma [l4]l  tells  us  that 
<£;  Af  i-  upcast[Ci;  Dj;  u;  et] :  {World  u )  ■  D,  Finally,  using  the  application 
formation  rule  n  times,  <£;  Ap  i-  e :  {World  u)  -C. 


Casel5.15l  e  =  new  C  (ei . . .  en),  where  T  e  Cj,  fields{C )  =  Di  fi...Dn  fn,  and 

C,  <:  D,  for  all  i  in  1 ...  n.  From  the  premise  <F;  A  i-  classes  :  {Classes  {World  u )  u } 
using  the  rules  for  selection  (of  C),  application,  and  selection  (of  new),  the  new 
component  has  type  {World  u)  ■  Di  —  . . .  {World  u )  ■  Dn  —  {World  u )  ■  C.  Just  as  in  the 
previous  case,  we  use  the  inductive  hypothesis  and  lemma [14] on  each  e,.  Again, 
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using  the  application  formation  rule  n  times  yields  A^  I-  e  :  ( World  u)  -  C. 

Case  15.161  follows  from  inductive  hypothesis  and  lemma  [l4| 

Case  15.171  e  =  (C)  eo  where  r  h  eo  e  D.  We  use  the  inductive  hypothesis  on  eo 
and  the  usual  unfold-open-unfold  sequence.  We  select  dyncast  from  the  vtab  and 
self-apply;  this  produces  a  polymorphic  function  of  type 

Vex.  (u^maybe  cx)^maybe  a 


Next  we  instantiate  a  with  ( World  u)  -C  and  apply  to  the  class  tag,  which  the 
correct  type:  maybe  ( World  u)-C.  The  result  has  type  maybe  {World  u)-C,  and 

using  the  case  formation  rule,  the  first  branch  has  type  ( World  u)-C.  The  other 
branch  aborts  evaluation,  but  is  regarded  as  having  the  same  type.  So,  finally, 

4>;  A{-  I-  e  :  {World  u )  ■  C.  □ 


5.8.5  Class  components 

Lemma  16  (Well-typed  constructor)  If  $  b  u  ::  Type  and 
<1>;  A  i-  vtab  :  Dict[ C]  {World  u)  u  ( SelfTy[C ]  {World  u)  u  Empty[C]),  then 
A  i-  new[C;  u;  vtab]  :  Ctor[ C]  {World  u). 


Proof  By  inspection,  using  lemma  [TT|  □ 

Lemma  17  (Well-typed  dictionary)  If  $  b  u  ::  Type,  <L;  A  h  inj :  {World  u)  -C^u,  and 
<L>;  A  i—  classes:  {Classes  {World  u)  u},  then 

A  h  dict[C;  u;  inj;  classes]  :  Vtail.  Dz'cf  [C]  {World  u)  u  {SelfTy[C]  {World  u)  u  tail). 


Proof  By  inspection,  using  lemma  10 


□ 


Theorem  5  (Well-typed  class  declaration)  <L;  A  h-  cdec[C]  :  ClassF[ C] 


Proof  By  inspection,  using  lemmas  [TB] and [T7| f or  the  non-trivial  class  components. □ 
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Theorem  6  (Well-typed  linkage) 

$;ih  link:  {(C :  ClassF[ C])  Cecn\  —  { Classes  ( World  Univ)  Univ} 

Proof  By  inspection.  □ 


5.9  Related  work 


Fisher  and  Mitchell  (1998)  use  extensible  objects  to  model  Java-like  class  constructs. 
Our  encoding  does  not  rely  on  extensible  objects  as  primitives,  but  it  may  be  viewed  as 
an  implementation  of  some  of  their  properties  in  terms  of  simpler  constructs.  Remy  and 
Vouillon  (1997)  use  row  polymorphism  in  Objective  ML  for  both  class  types  and  type 
inference  on  unordered  records.  Our  calculus  is  explicitly  typed,  but  we  use  ordered 
rows  to  represent  the  open  type  of  self. 

Because  it  uses  standard  existential  and  recursive  types,  our  object  representation 


is  superficially  similar  to  several  of  the  classic  encodings  in  Fm-based  languages  (Bruce, 
Cardelli,  and  Pierce  1999|  |Pierce  and  Turner  1994).  As  in  the  work  of|Abadi,  Cardelli, 
and  Viswanathan  (1996),  method  invocation  uses  self-application;  however,  we  hide  the 
actual  class  of  the  receiver  using  existential  quantification  over  row  variables  instead  of 
splitting  the  object  into  a  known  interface  and  a  hidden  implementation.  This  allows 
reuse  of  methods  in  subclasses  without  any  overhead.  We  use  an  analog  of  the  recursive- 
existential  encoding  due  to  Bruce  (1994)  to  give  types  to  other  arguments  or  results 
belonging  to  the  same  class  or  a  subclass,  as  needed  in  Java,  without  over-restricting 
the  type  to  be  the  same  as  the  receiver’s. 

Several  other  researchers  describe  type-preserving  compilation  of  object-oriented 
languages,  j Wright  et  al.  (1998)  compile  a  Java  subset  to  a  typed  intermediate  language, 
but  they  use  unordered  records  and  resort  to  dynamic  type  checks  because  their  sys¬ 
tem  is  too  weak  to  type  self  application.  Crary  (J_999 )  encodes  the  object  calculus  of 


Abadi  and  Cardelli  (1996|  using  existential  and  intersection  types  in  a  calculus  of  coer- 
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cions.  Glew  (2000a)  translates  a  simple  class-based  object  calculus  into  an  intermediate 
language  with  F-bounded  polymorphism  (|Canning  et  al.  19891  |Eifrig  et  al.  1995)  and  a 
special  ‘self  quantifier. 


Comparing  object  encodings 

A  more  detailed  comparison  with  the  work  of  Glew  and  Crary  is  worthwhile.  The  three 
encodings  share  many  similarities,  and  appear  to  be  different  ways  of  expressing  the 
same  underlying  idea.  In  this  section,  we  will  attempt  to  clarify  the  connections  between 
them.  Following  Bruce,  Cardelli,  and  Pierce  (1999),  we  can  specify  object  interfaces  as 
type  operators,  so  that  the  type  of  the  self  argument  can  be  plugged  in.  The  Poi  nt 
interface,  for  example,  would  be  represented  as  Ip  =  Aa::Type.  {getx  :  cv— int}. 

An  F-bounded  quantifier  ([Canning  et  al.  1989])  permits  a  quantified  type  variable  to 
appear  in  its  own  bound.  Glew  used  a  twist  on  F-bounded  polymorphism  to  encode 
method  tables  that  could  be  reused  in  subclasses.  This  leads  naturally  to  an  object 
encoding  using  an  F-bounded  existential  ( FBE)\  3a  <  1(a). a,  which  Glew  writes  as 
self  a.I(a).  Typically,  the  witness  type  is  recursive;  it  is  a  subtype  of  its  unrolling. 

The  connection  between  self  and  the  F-bounded  existential  was  recognized  indepen¬ 
dently  by  Glew  (2000c)  and  ourselves.  We  can  derive  the  rules  governing  self  from  those 
for  F-bounded  existentials.  Glew  uses  equi-recursive  types  in  (2000a);  a  restriction  to 
iso-recursive  types  is  possible,  though  awkward  (Glew  2000b).  The  rules  for  packing  and 
opening  self  types  must  simultaneously  fold  and  unfold  in  precisely  the  right  places. 

Self  application  is  typable  in  FEE  because  the  object,  via  subsumption,  enjoys  two 
types:  the  abstract  type  a  and  the  interface  type  1(a).  Crary  (1999)  encodes  precisely 
the  same  property  as  an  intersection  type:  3a.  a  a  7(a).  Again,  the  witness  type  is 
recursive.  With  equi-recursive  types,  a  value  of  type  p  I  also  has  type  I  (p  7);  it  could  be 
packaged  as  a/\I(a).  Crary  makes  this  encoding  practical  using  a  calculus  of  coercions— 
explicit  retyping  annotations.  Coercions  can  drop  fields  from  the  end  of  a  record,  fold 
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and  unfold  recursive  types,  mediate  intersection  types,  and  instantiate  quantified  types. 
All  coercions  are  erasable. 

We  will  now  show  how  our  own  encoding,  based  on  row  polymorphism,  relates  to 
these.  A  known  technique  for  eliminating  an  F-bound  is  to  replace  it  with  a  higher- 
order  bound  and  a  recursive  type.  That  is,  we  could  represent  3«  <  I  {a). a  as  35  < 
7.p  5.  Using  a  point -wise  subtyping  rule,  the  interface  type  operators  themselves  enjoy 
a  subtyping  relationship.  Iso-recursive  types  can  be  used  directly  with  this  technique 
because  the  fixed  point  is  separate  from  the  existential. 

Next,  though  it  is  less  efficient,  we  can  implement  the  higher-order  subtyping  with 
a  coercion  function: 

35  ::  Type=>Type.{c  :  5  (p  5)  —  I  (p  5),  o  :  p  5} 

To  select  a  method  from  an  object,  we  first  open  the  package,  select  the  coercion  c,  and 
apply  it  to  the  unfolding  of  o.  This  yields  an  interface  whose  methods  are  then  directly 
applicable  to  o.  Now  we  no  longer  require  sub  typing. 

Using  a  general  function  for  this  coercion  yields  more  flexibility  than  we  require  to 
implement  Java.  All  the  function  ever  needs  to  do  is  drop  fields  from  records.  With  row 
polymorphism,  we  can  express  the  result  of  pre-applying  the  coercions  at  all  levels.  Now 
we  no  longer  require  inefficient  coercions.  The  encodings  of  Crary  and  Glew  work  by 
supplying  two  distinct  views  of  the  object:  an  abstract  subtype  of  a  concrete  interface 
type.  With  row  polymorphism,  that  distinction  is  unnecessary;  we  can  hide  just  the 
unknown  portion  of  the  interface  directly. 

All  three  of  these  encodings  appear  to  be  efficient.  In  an  untyped  dynamic  semantics, 
their  object  representations  are  precisely  the  same.  The  major  differences  among  them 
are  in  the  strength  of  the  underlying  type  theory:  Glew  uses  subtyping  and  F-bounded 
quantifiers;  Crary  uses  intersection  types;  we  use  row  polymorphism.  In  our  experience, 
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row  polymorphism  is  the  most  conservative  extension  to  plain  F^—  they  hardly  affect 
the  soundness  proof  at  all.  Subtyping  and  F-bounded  quantifiers  are  a  more  drastic 
extension  to  Fco.  To  our  knowledge,  ours  is  the  only  one  of  these  encodings  to  have 
been  implemented  in  a  real  system. 


Chapter  6 


Beyond  Featherweight:  the  rest  of  Java 


Chapters  [3]  through  [5]  presented  the  major  theoretical  results  of  this  dissertation:  an 
object-oriented  source  language,  a  sound  and  decidable  target  language,  a  formal  type¬ 
preserving  translation,  and  proofs  of  many  important  properties.  The  remaining  chap¬ 
ters  supplement  these  theoretical  results  by  discussing  how  they  extend  to  a  full  system 
and  by  examining  many  implementation  issues. 

Featherweight  Java,  of  course,  is  only  the  most  rudimentary  fragment  of  the  full  Java 
language.  It  includes  classes,  inheritance,  dynamic  dispatch,  and  dynamic  casts.  It  was 
ideal  for  the  formal  part  of  our  work  because  it  made  the  translation  and  proofs  rea¬ 
sonably  comprehensible.  Our  implementation,  however,  supports  many  Java  features 
that  are  not  part  of  FJ:  interfaces,  constructors,  static  members,  null  objects,  mutable 
fields,  super  calls,  exceptions,  and  privacy.  Some  advanced  features  of  Java  are  not 
currently  supported,  but  are  the  subject  of  ongoing  research:  protected  and  package 
scopes,  native  code,  dynamic  class  loading,  the  reflection  API,  and  concurrency. 

This  chapter  informally  describes  some  significant  extensions  to  our  translation.  We 
believe  that,  given  a  Java  calculus  with  these  extensions,  the  type  preservation  theorem 
would  still  hold.  Unfortunately,  Java  formalizations  with  these  additional  features  are 


easily  an  order  of  magnitude  more  complex  than  FJ— see  Drossopoulou  and  Eisenbach 
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(19991  or  Flatt,  Krishnamurthi,  and  Felleisen  (1999),  for  example.  We  have  not  found 
a  way  to  manage  such  additional  complexity  in  our  translation  while  still  maintaining 
readability  and  detailed  proofs. 

We  begin  with  features  that  are  handled  relatively  easily  in  our  translation,  even 
though  some  of  them  are  tough  to  formalize.  Static  members,  interface  fields,  and 
multiple  parameterized  constructors  can  be  added  to  the  class  record,  along  with  the 
dictionary  and  tag.  Mutable  fields  are  easily  modeled  using  mutable  records.  As  re¬ 
quired  by  the  JVM,  the  new  function  allocates  the  object  record  with  a  default  ‘zero’ 
value  for  each  field.  Then  any  public  constructor  can  be  invoked  to  assign  new  values 
to  the  fields.  Super  invocations  select  the  method  statically  from  the  super  class  dictio¬ 
nary  (as  is  currently  used  in  dyncast).  Java  exceptions  work  similarly  to  those  of  SML. 
Java’s  instanceof  uses  the  same  mechanism  as  dynamic  cast,  but  is  simpler  since  it  just 
returns  a  boolean  value. 

Private  methods  are  defined  along  with  the  other  methods.  Since  they  can  neither 
be  called  from  subclasses  nor  overridden,  we  simply  omit  them  from  the  vtable  and 
dictionary.  We  do  not  yet  support  protected  and  package  scopes,  however,  because 
they  transcend  compilation  unit  boundaries.  In  Moby,  [Fisher  and  Reppy  (1999  )  use  two 
distinct  views  of  classes,  a  class  view  and  an  object  view.  These  correspond  roughly  to 
the  diet  and  new  fields  of  our  class  encoding.  If  we  export  a  class  outside  its  definitional 
package,  all  protected  methods  and  fields  should  be  hidden  from  the  object  view  but 
not  the  class  view  while  those  of  package  scope  should  be  hidden  from  both. 

Null  references  are  easily  encoded  by  lifting  all  external  object  types  to  sum  types 


with  a  null  alternate  (just  like  the  maybe  type).  Then,  all  object  operations  must  verify 
that  the  object  pointer  is  not  null.  Our  target  calculus,  unlike  JVML,  can  express  that  an 
object  is  non-null,  so  null  pointer  checks  can  be  safely  hoisted. 
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6.1  Private  fields 

Private  fields  can  be  hidden  from  outsiders  using  existential  types.  For  convenience, 
assume  that  the  private  fields  of  each  class  in  the  hierarchy  are  collected  into  separate 
records.  Suppose  that  Point  has  private  fields  x  and  y,  and  public  field  z;  and  ScaledPoint 
has  private  field  s.  The  layout  for  a  Scaled  Point  object  would  be  {vtab,  Pt :  {x,  y} ,  z,  SPt :  {s}} 
With  the  private  fields  separated  like  this,  it  is  easy  to  hide  their  types  separately.  (Using 
a  flat  representation  is  possible,  but  this  separation  allows  a  simpler,  more  orthogonal 
presentation.)  We  embed  each  class  functor  in  an  existential  package,  where  the  witness 
type  includes  the  types  of  the  private  fields  of  that  class: 


C pi  =  (priv::Type  =  {x,  y},  CDEC[Pt] : . . .) 


From  inside  class  ScaledPoint,  we  open  the  Point  package,  binding  a  type  variable  a  to 
represent  the  private  fields  of  Point: 


Cspt  =  open  Cpt  as  («::Type,  super: . . .) 

in  (priv::Type  =  {s},  CDEC[SPt] :. . .) 

Then,  our  local  view  of  the  object  from  within  the  subclass  is 


{vtab,  Pt : cx,  z,  SPt:  { s} } 


As  required,  the  private  fields  of  the  super  class  are  hidden.  Using  dot  notation  (Cardelli 
and  Leroy  1990)  for  existential  types  (instead  of  open)  makes  this  encoding  more  con¬ 
venient,  but  is  not  necessary. 


Unfortunately,  privacy  interacts  with  mutual  recursion.  Suppose  that  A  has  a  pri¬ 
vate  field  b  of  class  B  and  that  B  has  a  method  getA  that  returns  an  object  of  class  A. 
From  within  class  A,  accessing  this.b  is  allowed,  as  is  invoking  this.b.getA( ).  It  is  more 
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difficult  to  design  an  encoding  that  also  allows  this.b.getA(  ).b.  Using  the  existential 
interpretation  of  privacy  described  above,  each  class  has  its  own  view  of  the  types  of  all 
other  objects.  From  within  class  A,  private  fields  of  other  objects  of  class  A  are  visible. 
Private  fields  of  objects  of  other  classes  are  hidden,  represented  by  type  variables.  In 
our  example,  this.b  would  have  a  type  something  like  “B  with  private  fields  /l”  where  /I 
is  the  abstract  type.  Likewise,  from  within  class  B,  the  type  of  method  getA  might  be 
self-*(“A  with  private  fields  cv”).  The  challenge  is  to  allow  class  A  to  see  that  the  a  in 
the  type  of  getA  is  actually  the  known  type  of  its  own  private  fields. 

Propagating  this  information  is  especially  tricky  given  the  limitations  of  the  iso¬ 
recursive  types  used  in  our  target  calculus.  We  found  a  solution  that  does  not  require 
extending  the  language.  We  parameterize  everything  (including  the  hidden  type  itself) 
by  the  types  of  objects  of  other  classes.  Then,  each  class  can  instantiate  the  types  of 
the  rest  of  the  world  using  concrete  types  for  its  own  private  fields  (wherever  they  may 
lurk  in  other  classes)  and  abstract  types  for  the  rest.  The  issues  are  subtle,  and  a  formal 
treatment  is  outside  the  scope  of  my  thesis. 

Extending  Featherweight  Java  with  privacy  would  help  elucidate  the  technique,  but 
this  in  itself  is  non-trivial.  Were  we  to  extend  FJ  and  formalize  a  translation  with  privacy, 
we  would  then  like  to  prove  that  privacy  is  preserved  in  the  target  language.  That 
is,  we  would  expect  the  type  system  to  ensure  that  another  module  (even  if  it  is  not 
translated  from  Java)  cannot  access  the  private  fields.  Unfortunately,  this  would  not 
be  a  corollary  of  the  type  preservation  theorem.  Rather,  it  is  related  to  a  property 
called  full  abstraction,  meaning  that  abstraction  properties  in  the  source  language  are 
also  protected  in  the  target  language.  It  is  still  unclear  whether  our  encoding— or  the 
encodings  of  Crary  (1999)  or  Glew  (2000a),  for  that  matter— enjoys  full  abstraction. 
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6.2  Interfaces 


Given  an  object  of  interface  type,  we  know  nothing  about  the  shape  of  its  vtable.  There 


are  various  ways  of  locating  methods  in  interface  objects.  Proebsting  et  al.  (19971  con¬ 


struct  a  per-class  dictionary  that  maps  method  names  to  offsets  in  the  vtable.  Krall 
and  Grafl  (1997)  construct  a  separate  method  table  (called  an  itable)  for  each  declared 
interface,  storing  them  all  somewhere  in  the  vtable.  Although  they  are  not  clear  on  how 
to  use  the  itable,  there  appear  to  be  two  choices.  First,  we  can  search  for  the  appropriate 
itable  in  the  vtable,  which  amounts  to  lookup  of  interface  names  rather  than  method 
names.  Second,  when  casting  an  object  from  class  type  to  interface  type,  we  can  select 
the  itable  and  then  pair  it  with  the  object  itself.  This  avoids  name  lookup  entirely  but 
requires  minor  coercions  when  casting  to  and  between  interface  types. 

Our  translation  can  be  extended  to  support  both  strategies.  For  the  first  strategy,  all 
we  need  is  to  introduce  unordered  records  into  our  target  language  with  a  primitive  for 
dictionary  lookup.  This  just  means  that  records  with  permuted  fields  are  considered 
equivalent,  and  that  selecting  a  field  from  a  record  is  expensive  because  offsets  must 
be  computed  at  run  time.  All  the  itables  for  a  class  would  be  collected  into  a  separate 
unordered  record,  itself  an  element  of  the  still  ordered  vtable.  Then,  casting  an  object 
to  an  interface  type  only  requires  repackaging  (a  runtime  no-op)  to  hide  those  entries 
not  exported  by  the  current  interface. 

We  can  also  follow  the  latter  strategy,  representing  interface  objects  as  a  pair  where 
the  type  of  the  underlying  object  is  concealed  by  an  existential  type.  For  example,  an 
object  which  implements  the  Runnable  interface  includes  a  method  run( )  which  can  be 
invoked  to  start  a  new  thread.  In  our  target  language,  a  Runnable  object  r  is  represented 
as  3a::Type.  { itab  :  {run :  a—  1 },  obj : «}.  To  invoke  the  method,  we  open  the  existential, 
select  the  method  from  the  itab,  select  the  obj,  and  apply.  With  this  representation, 
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interface  method  invocations  are  about  the  same  cost  as  normal  method  invocations: 

open  r  as  (/?:: Type,  z :  {itab :  {run  :/J—  1 },  obj :  jS}> 
in  z. itab. run  (z.obj) 

The  caveat  is  that  upward  casts  to  interface  types  are  no  longer  free.  To  perform  the 
cast,  we  must  select  the  target  interface’s  itable  from  the  object  and  pair  it  with  the 
object  itself. 


Chapter  7 


Functional  Java  Bytecode 


We  have  presented  a  formal  translation  of  a  Java  calculus,  proved  that  it  preserves  types, 
and  argued  that  it  can  be  extended  to  most  of  Java.  Now,  we  turn  to  more  detailed 
implementation  concerns.  The  first  design  decision  we  encountered  was  whether  to 
accept  Java  source  code  as  input!  An  interesting  alternative  is  to  accept  the  output 
of  javac:  class  files  containing  Java  bytecode,  also  known  as  the  Java  Virtual  Machine 
Language  (JVML). 

Although  JVML  uses  untyped  local  variables  and  is  difficult  to  analyze,  in  some  ways 
it  contains  more  information  than  Java  source  code.  Identifiers  are  already  resolved, 
and  the  types  of  all  fields  and  methods  mentioned  in  the  code  are  included— even  if 
they  are  defined  in  other  classes.  We  decided  to  let  javac  perform  these  menial  tasks, 
so  that  we  could  concentrate  on  compiling  JVML  to  a  typed  intermediate  language.  This 
has  been  a  fruitful  path. 

In  compiling  JVML,  there  are  two  orthogonal  sets  of  issues.  The  first  set,  which 
we  addressed  in  the  formal  translation,  concerns  encoding  Java  features  like  method 
invocation  and  dynamic  cast.  The  second  set  of  features  has  to  do  with  control  and  data 
flow.  Java  bytecode  is  a  linear  instruction  stream  that  uses  an  implicit  operand  stack, 
untyped  local  variables,  and  jumps. 
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To  realize  this  separation  of  concerns  in  our  implementation,  we  designed  AJVM  as 
an  intermediate  language  that  sits  between  JVML  and  JFlint.  Its  control  and  data  flow 
are  just  like  a  A-calculus,  but  it  retains  the  types  and  primitive  instructions  of  JVML. 

Apart  from  its  role  in  our  system,  AJVM  is  a  good  alternative  to  Java  bytecode  for 
virtual  machines  or  compilers  which  optimize  methods  and  produce  native  code.  It  is 


already  in  a  form  that,  like  static  single  assignment  (jAlpern,  Wegman,  and  Zadeck  1988), 
makes  data  flow  explicit.  In  addition,  AJVM  is  cleaner  to  specify  and  simpler  to  verify 
than  JVML. 


7.1  Design 

AJVM  is  a  simply-typed  A-calculus  expressed  in  A-normal  form  (Flanagan  et  al.  1993) 
and  extended  with  the  types  and  primitive  instructions  of  the  Java  virtual  machine.  The 
syntax  is  given  in  figure  [77T|  on  the  next  page.  We  use  terms  e  in  place  of  the  bytecode 
for  method  bodies;  otherwise  the  class  file  format  remains  the  same.  A-normal  form 
ensures  that  functions  and  primitives  are  applied  to  values  only;  the  1  et  syntax  binds 
intermediate  values  to  names.  A  nested  algebraic  expression  such  as  (3  +  4)  x  5  is 
expressed  in  A-normal  form  as  1  et  x  =  3  +  4 ;  lety  =  xx  5;  return  y. 

By  simply-typed,  we  mean  that  there  are  primitive  and  function  types,  but  no  poly¬ 
morphic  or  user-defined  type  constructors.  Types  include  integers  I,  floats  F,  and  the 
rest  of  Java’s  primitive  types.  V  is  the  void  type,  used  for  methods  or  functions  which 
do  not  return  a  value.  Class  or  interface  names  c  also  serve  as  types.  c°  indicates 
an  uninitialized  object  of  class  c.  We  describe  our  strategy  for  verifying  proper  object 
initialization  in  section  [7731 

The  set  type  {c}  represents  a  union.  Normally  we  can  treat  {a,  b,c}  as  equivalent 
to  the  name  of  the  class  or  interface  which  is  the  least  common  ancestor  of  a,  b,  and  c 
in  the  class  hierarchy.  For  interfaces,  however,  a  usable  ancestor  does  not  always  exist; 
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Types  t  ::=  I  |  F  |  . . .  |  V  |  c  |  t  [] 

I  c°  |  {c}  |  (t)  -»  T 

Values  v  ::=  x  \  i  \  r  \  s  \  nul  1  [r]  |  A  ( x  :  r  )  e 

Terms  e  ::=  1  etrec  x  =  v  .  e  |  let  x  =  g ;  e  \  g;  e 

|  i  f  br[r ]  v  v  then  e  el  se  e 
|  return  |  return  v  \  v  ( v )  |  throw  v 

Guards  g  ::=  p  \  p  handle  v  (v) 

Primops  p  ::=  new  c  \  chkcast  c  v  |  i  nstanceof  c  v 
|  getf i  el  d  fd  v0  I  putf i  el  d  fd  v0  v 
|  getstatic  fd  \  putstatic  fd  v 
|  i  nvokevi  rtual  mdv0  (u") 

|  i  nvokei  nterface  md  u0  (V) 

|  i  nvokespeci  al  mdv0  ( v  ) 

|  invokestatic  md  (  v  ) 

|  bo[r ]  v  v  |  neg[r]  v  \  convert[ro,  Ti]  v 

|  newarray[r]  vn  \  arrayl ength[r]  va 
|  al oad[T ]  va  vt  \  astore[T]  va  v0 

Branches  br  ::=  eq  |  ne  |  It  |  le  |  gt  |  ge 
Binops  bo  ::=  br  \  add  |  mul  I  div  |  and  j  or  |  . . . 

Field  descriptor  fd  ::=  r  c.f 
Method  descriptor  md::=c.m(r')T 


Figure  7.1:  Method  syntax  in  AJVM 


see  section [7G]  Finally,  (r)  —  r  is  the  type  of  a  AJVM  function  with  multiple  arguments. 

Values  include  names  x  (introduced  by  1  et),  constants  of  various  types,  the  null 
constant  (nul  1  [r]  for  a  given  array  or  object  type  r),  and,  finally,  anonymous  functions 
A  ( x  :  r  )  e.  The  names  and  types  of  arguments  are  written  inside  the  parentheses,  and 
followed  by  e,  the  function  body. 

Terms  include  two  binding  forms:  1  etrec  binds  a  set  of  mutually  recursive  func¬ 
tions;  let  x  =  g;  e  executes  the  (possibly  guarded)  primitive  operation  g,  binds  the 
result  to  x,  and  continues  executing  e.  If  we  are  uninterested  in  the  result  of  a  primop 
(or  it  does  not  produce  a  result),  the  sequencing  form  g ;  e  may  be  used  instead  of 
let.  The  guard  handle  v  (v  )  on  a  primitive  indicates  where  to  jump  if  the  operation 
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throws  an  exception.  Conditional  branches  are  used  for  numeric  comparisons  and  for 
testing  whether  reference  values  are  null.  For  brevity,  we  omit  the  1  ookupswi  tch  and 
tableswitch  of  the  Java  virtual  machine.  Finally,  the  base  cases  can  return  (with  an 
optional  value),  call  a  function,  or  throw  an  exception. 

The  primitive  operations  cover  those  JVML  instructions  that  are  not  for  control  flow 
or  stack  manipulation.  They  may  be  grouped  into  three  categories:  object,  numeric, 
and  array.  Object  primops  include  new,  the  dynamic  cast  and  instanceof  predicate, 
field  accesses,  and  method  calls.  Field  and  method  descriptors  include  the  class  name 
and  type,  just  as  they  do  in  the  JVM.  Numeric  primops  are  the  usual  arithmetic  and 
conversions.  Branches,  when  used  as  primops,  return  boolean  values.  Array  primops 
create,  subscript,  update,  and  return  the  length  of  an  array.  We  use  square  brackets  for 
type  parameters  which,  in  JVML,  are  part  of  the  instruction.  Thus,  i  add  is  expressed  as 
add[I],  fmul  is  mul  [F],  and  i  2f  is  convert[I,  F],  We  omit  multi-dimensional  arrays, 
moni  torenter  and  moni  torexi  t  for  brevity. 

There  are  three  important  things  to  note  about  AJVM.  First,  it  is  functional.  There  is 
no  operand  stack,  no  local  variable  assignment,  and  all  data  flow  is  explicit.  Second,  it  is 
impossible  to  call  a  function  and  continue  executing  after  it  returns:  lety  =  /  ( x ) ;  ... 
is  not  valid  syntax.  Therefore  all  function  calls  can  be  implemented  as  jumps.  (Tail  call 
optimization  is  standard  practice  in  compilers  for  functional  languages.)  This  makes 
AJVM  functions  very  lightweight;  more  akin  to  basic  blocks  than  to  functions  in  C. 

Third,  functions  are  first  class  and  lexically  scoped.  We  use  higher-order  functions 
to  implement  subroutines  and  exception  handlers.  Importantly,  functions  in  AJVM  can¬ 
not  escape  from  the  method  in  which  they  are  declared.  Except  for  the  entry  point  of  a 
method,  call  sites  of  all  A-functions  are  known.  This  means  a  compiler  is  free  to  use  the 
most  efficient  calling  convention  it  can  find.  Typically,  each  higher-order  function  is  rep¬ 
resented  as  a  closure— a  pair  of  a  function  pointer  and  an  environment  containing  values 
for  the  free  variables  (I.andin _1964).  This  representation  is  convenient,  consistent,  and 
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public  static 
Pt  p  =  new 
for  (int  j 
p  =  new 

} 

p.drawO  ; 
return ; 


void  m  (int 
IntPt(i) ; 

=  1 ;  j  <  i ; 

ColorPt(j) ; 


i)  { 

j  *= 


2)  { 


Figure  7.2:  A  sample  Java  method  with  a  loop 


compatible  with  separate  compilation,  but  many  other  techniques  are  available.  Our 
implementation  currently  uses  defunctionalization  (Reynolds  19721,  but  that  is  just  a 
detail. 

Kelsey  (19951  and  Appel  (19981  have  observed  that  A-normal  form  for  functional 


programs  is  equivalent  to  the  static  single  assignment  (SSA)  form  used  in  many  opti¬ 
mizing  compilers  to  make  analyses  clean  and  efficient.  This  is  why  AJVM  is  preferable 
to  stack-based  Java  bytecode  for  virtual  machines  and  compilers  that  optimize  methods 
and  produce  native  code— it  is  already  in  a  format  suitable  for  analysis,  optimization, 
and  code  generation.  Furthermore,  as  we  discuss  in  section[A3|  type  checking  for  AJVM 
is  far  simpler  than  standard  class  file  verification. 


7.2  Translation 


In  this  section,  we  describe  informally  how  to  translate  JVM  bytecode  to  AJVM.  Figure [772] 
contains  a  simple  Java  method  which  creates  objects,  invokes  a  method,  and  updates 
a  loop  counter.  Suppose  that  IntPt  and  ColorPt  are  both  subclasses  of  Pt.  With  this 
example,  we  will  demonstrate  set  types  and  mutable  variable  elimination. 


Figure  7.3  shows  the  bytecode  produced  by  the  Sun  Java  compiler.  The  first  step 


in  transforming  the  bytecode  to  AJVM  is  to  find  the  basic  blocks.  This  method  begins 
with  a  block  that  allocates  and  initializes  an  IntPt,  initializes  j,  then  jumps  directly 


98 


CHAPTER  7.  FUNCTIONAL  JAVA  BYTECODE 


public  static  m(I)V 
new  IntPt 
dup 

i load_0 

i nvokespeci al  IntPt . <i ni t>(I)V 
astore_l  ;  p  =  new  IntPt(i) 

i const_l 

istore_2  ;  j  =  1 

goto  C 

B:  new  ColorPt 
dup 

i load_2 

i nvokespeci al  ColorPt . <i ni t>(I)V 
astore_l  ;  p  =  new  ColorPt(j) 

i load_2 
i const_2 
i  mul 

istore_2  ;  j  *=  2 

C:  iload_2 
i load_0 

i f_i cmpl t  B  ;  goto  B  i f  j  <  i 

aload_l  ;  p.draw() 

i nvokevi rtual  Pt.draw()V 
return 

Figure  7.3:  The  same  method  compiled  to  JVML 


public  static  m(I)V  =A(i:I) 
letrec  C  =  A  (  p  :  {IntPt,  ColorPt},  j:  I) 
if  lt[I]  j  i  then  B(p,j) 
else  i nvokevi  rtual  Pt.draw()V  p  (); 
return . 

B  =  A  (  p  :  {IntPt,  ColorPt},  j:  I) 
let^  =  new  ColorPt; 

i  nvokespeci  al  Col  orPt.ci  ni  t>(I)V  q  ( j  ); 

1  et  k  =  mul [I]  j  2 ; 

C(q,k). 

let  r  =  new  IntPt ; 

i  nvokespeci  al  IntPt. <i  ni  t>(I)V  r  (i); 

C  ( r,  1) 

Figure  7.4:  The  same  method  translated  to  AJVM 
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to  block  C.  C  does  the  loop  test  and  either  jumps  to  B  (the  loop  body)  or  falls  through 
and  returns.  The  loop  body  creates  a  Col  orPt,  updates  the  loop  counter,  and  then  falls 
through  to  the  loop  test. 

Next,  data  flow  analysis  must  infer  types  for  the  stack  and  local  variables  at  each 
program  point.  This  analysis  is  also  needed  during  bytecode  verification.  In  the  be¬ 
ginning,  we  know  that  local  variable  0  contains  the  method  argument  i  and  the  stack 
is  empty.  (For  virtual  methods,  local  0  contains  thi  s.)  Symbolic  execution  of  the  first 
block  reveals  that,  upon  jumping  to  C,  local  1  contains  an  IntPt  and  local  2  contains 
an  i  nt.  We  propagate  these  types  into  block  C,  and  from  there  into  block  B.  During 
symbolic  execution  of  B,  we  store  a  Col  orPt  into  local  i.  Since  the  current  type  of  local 
1  is  IntPt,  we  must  unify  these.  Fortunately,  we  can  unify  these  in  AJVM  without  even 
knowing  where  they  fit  into  the  class  hierarchy— we  simply  place  them  into  a  set  type. 
Now  local  1  has  type  {IntPt,  ColorPt}.  If  two  types  cannot  be  unified  (i  nt  and  IntPt, 
for  example),  then  the  variable  is  marked  as  unusable  (voi  d).  Block  C  is  a  successor 
of  B,  and  since  the  type  of  local  I  has  changed,  we  must  check  it  again.  Nothing  else 
changes,  so  the  data  flow  is  complete  and  we  know  the  types  of  the  locals  and  the  stack 
at  the  start  of  each  block. 

Next  we  use  symbolic  execution  to  translate  each  block  to  a  A-function.  The  type 
annotations  within  each  A-binding  come  directly  from  the  type  inference.  For  each 
instruction  which  pushes  a  value  onto  the  operand  stack,  we  push  a  value  (either  a 
fresh  name  or  a  constant)  onto  the  symbolic  stack.  For  each  instruction  which  fetches 
its  operands  from  the  stack,  we  harvest  the  values  from  the  symbolic  stack  and  emit  the 
corresponding  primop.  Figure [7~4] shows  the  resulting  code.  The  method  is  a  A-function 
with  an  argument  i.  B  and  C  are  functions  implementing  the  basic  blocks  of  the  same 
name,  and  the  code  of  the  first  block  follows.  The  loop  counter  is  updated  by  passing  a 
new  value  to  function  C  each  time  around  the  loop.  Since  the  argument  i  is  unchanged 
in  the  method,  we  have  lifted  its  binding  so  that  the  other  two  blocks  are  within  its 
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scope. 

We  used  this  rather  simple  example  to  illustrate  the  basic  principles,  but  two  JVML 
features  prove  quite  challenging:  subroutines  and  exception  handlers. 


7.2.1  Subroutines 


The  Java  compiler  uses  subroutines  to  implement  f  i  nal  1  y  blocks  (Lindholm  and  Yellin 
19991.  Other  compilers  that  target  JVML  could,  of  course,  use  them  for  other  reasons. 
The  j  s  r  instruction  pushes  a  return  address  onto  the  stack  and  transfers  control  to  the 
specified  label.  The  ret  instruction  jumps  back  to  the  return  address  in  the  specified 
local  variable. 

Subroutines  pose  three  major  challenges.  First,  they  are  “polymorphic  over  the  types 
of  the  locations  they  do  not  touch”  (Stata  and  Abadi_1998l.  As  long  as  a  subroutine 
ignores  local  2,  say,  it  could  contain  an  integer  at  one  call  site  and  a  float  at  another. 
Second,  since  return  addresses  can  be  stored  in  local  variables,  subroutine  calls  and 
returns  need  not  obey  a  stack  discipline.  Indeed,  they  need  not  return  at  all.  In  Java,  we 
need  only  to  place  a  break  or  conti  nue  inside  a  fi  nal  1  y  block  to  produce  a  subroutine 
which  ignores  its  return  address  and  jumps  elsewhere.  Finally,  a  subroutine  might 
update  a  local  variable.  Since  locals  are  not  mutable  in  A  JVM,  the  subroutine  must 
explicitly  pass  the  new  value  back  to  the  caller. 

We  solve  these  problems  using  the  continuation-passing  idiom  from  functional  pro¬ 
gramming.  The  subroutine  takes  a  higher-order  function  (called  the  return  continuation ) 
in  place  of  a  return  address.  Any  values  the  subroutine  might  change  are  passed  to  the 
return  continuation  as  arguments;  any  free  variables  in  the  continuation  are  preserved 
across  the  call. 


An  example  is  worthwhile;  see  figure  [775]  on  the  facing  page.  The  subroutine  S  has 
two  call  sites.  In  the  first,  local  1  is  uninitialized;  in  the  second,  it  contains  a  string.  The 
subroutine  either  updates  local  0  and  returns  normally  or  jumps  directly  to  the  end  of 
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public  static  f(I)V 
jsr  S 

ldc  "Hello" 
astore_l 
L:  jsr  S 
al  oacLl 
invoke  println 
goto  L 

S:  astore_2  ;  ret  addr 
i 1 oad_0 
i  feq  R 
iinc  0  -1 
ret  2 
R:  return 


Figure  7.5:  A  complex  example  with  subroutines 

public  static  f(I)V  =  A(n:I) 
letrec  S  =  A  (  i  :  I,  r:(  I)  —  V ) 

if  eq[I]  i  0  then  return 
else  let  j  =  add[I]  i  -1; 
r{j). 

L  =  A  (  i  :  I,  s  :  String) 

S  ( i,  A  ( j  :  I )  i  nvoke  pri  ntl  n  s  ;  L(j,s)). 

S  (n,  \  (j  :  I)  L(j,  "Hello")) 


Figure  7.6:  Translation  involving  subroutines 


the  method.  Bytecode  verification  is  much  trickier  in  the  presence  of  subroutines,  and 
our  type  inference  phase  is  no  different.  We  must  unify  the  types  of  locals  at  different 
call  sites,  and  decide  which  are  passed  to  the  subroutine,  which  are  passed  back  to  the 
caller,  and  which  are  otherwise  preserved  across  the  call. 

A  translation  of  the  example  appears  in  figure  |7.6[  The  subroutine  S  takes  an  ar¬ 
gument  r  of  type  (I)  —  V;  this  is  the  return  continuation.  In  one  branch,  it  returns 
from  the  method,  in  the  other,  it  jumps  to  the  continuation,  passing  the  new  value  of 
local  0.  Now  consider  the  two  call  sites  of  S.  Inside  L  the  string  s  is  a  free  variable  of 
the  functional  argument,  so  it  is  preserved  across  the  call. 


This  solution  works  quite  well.  We  used  Jasmin,  a  JVML  assembler  (Meyer  and  Down- 
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ing  1997),  to  generate  a  series  of  convoluted  test  cases  that  do  not  arise  from  typical 
Java  compilers.  Our  code  translated  all  of  them  correctly.  We  emphasize  again  that 
these  higher-order  functions  can  be  compiled  away  quite  efficiently  in  AJVM  since  all 
call  sites  are  known. 


7.2.2  Exception  handlers 


The  throw  expression  should  only  be  used  to  signal  exceptions  that  exit  the  current 
method.  For  exceptions  handled  within  the  current  method,  we  jump  directly  to  a 
block  implementing  the  handler.  The  handl  e  suffix  on  primitive  operations  is  inspired 
by  the  also-unwinds-to  feature  of  C —  (Ramsey  and  Peyton  Jones  2000),  and  it  serves  two 
distinct  purposes. 

Consider  a  primitive  (such  as  getf  i  el  d)  that  might  raise  an  exception,  but  that  will 
later  be  expanded  to  low-level  code.  The  code  will  first  perform  a  null  check.  If  it 
succeeds,  the  offset  corresponding  to  the  field  is  dereferenced.  If  the  check  fails,  then 
an  exception  is  thrown.  In  this  case,  once  the  null  check  is  expanded,  the  failure  branch 
jumps  directly  to  the  handler  and  the  handl  e  annotation  disappears. 

Primitives,  such  as  method  invocation,  that  involve  out-of-method  function  calls 
work  differently.  In  these  cases,  the  exception  could  be  thrown  further  down  the  call 
stack.  The  handl  e  annotation  indicates  to  the  compiler  that  the  function  has  an  abnor¬ 


mal  return  path.  The  th  row,  then,  is  just  an  abnormal  return.  Ramsey  and  Peyton  Jones 
(2000)  describe  a  code  generation  trick  due  to  Atkinson,  Liskov,  and  Scheifler  (1978) 
where  a  table  of  continuation  branches  follows  the  call  instruction.  By  adding  an  offset 
to  the  return  address,  the  callee  can  select  which  return  path  to  take. 

In  contrast  to  Java,  AJVM  does  not  specify  a  series  of  handlers  based  on  the  exception 


sub-class.  The  single  handler  must  explicitly  query  the  dynamic  class  of  the  exception 
and  dispatch  accordingly. 
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7.3  Verification 


The  JVM  specification  (Lindholm  and  Yellin  19991  defines  a  conservative  static  analy¬ 


sis  for  verifying  the  safety  of  a  class  file.  Code  which  passes  verification  should  not, 
among  other  things,  be  able  to  corrupt  the  virtual  machine  which  executes  it.  One  of  the 
primary  benefits  of  AJVM  is  that  verification  reduces  to  simple  type  checking.  Most  of 
the  analyses  required  for  verification  are  performed  during  translation  to  AJVM.  The  re¬ 
sults  are  then  preserved  in  type  annotations,  so  type  checking  can  be  done  in  one  pass. 
Our  type  checker  is  less  than  260  lines  of  ML  code,  excluding  the  AJVM  data  structure 
definitions. 


Two  of  the  most  complex  aspects  of  class  file  verification  are  subroutines  (Stata 
and  Abadi  1998)  and  object  initialization  (|Freund  and  Mitchell  1999).  We  have  already 
seen  how  subroutines  disappear,  but  let  us  explore  in  detail  the  problem  of  object 
initialization. 


7.3.1  Object  initialization 


Our  explanation  of  the  problem  follows  that  of  Freund  and  Mitchell  (19991.  In  Java 
source  code,  the  new  syntax  allocates  and  initializes  an  object  simultaneously: 

Pt  p  =  new  Pt(i);  p.drawQ; 


In  bytecode,  however,  these  are  separate  instructions: 


new  Pt 

;  alloc 

dup 

i 1 oad_0 

i nvokespeci al 

Pt, 

.  <init>(I)V 

;  init 

i nvokevi rtual 

Pt, 

.  drawQV 

;  use 

Between  allocation  and  initialization,  the  pointer  can  be  duplicated,  swapped,  stored  in 
local  variables,  etc.  Once  we  invoke  the  initializer,  all  instances  of  the  pointer  become 
safe  to  use.  We  must  track  these  instances  with  some  form  of  alias  analysis.  The 
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following  code  creates  two  points;  the  verifier  must  determine  whether  the  drawn  point 

is  properly  initialized. 

1:  new  Pt 
2 :  dup 
3:  new  Pt 
4 :  swap 

5:  i nvokespeci al  Pt.<init>()V 
6 :  pop 

7:  i nvokevi rtual  Pt.draw()V 

This  code  would  be  incorrect  without  the  pop. 

Lindholm  and  Yellin  (1999f  describe  the  conservative  alias  analysis  used  by  the  Sun 
verifier.  The  effect  of  the  new  instruction  is  modeled  by  pushing  the  Pt  type  onto  the 
stack  along  with  an  ‘uninitialized’  tag  and  the  offset  of  the  instruction  which  created  it. 
To  model  the  effect  of  the  initializer,  update  all  types  with  the  same  instruction  offset, 
marking  them  as  initialized.  Finally,  uninitialized  objects  must  not  exist  anywhere  in 
memory  during  a  backward  branch. 

In  AJVM,  many  aliases  disappear  with  the  local  variable  and  stack  manipulations. 

Every  value  has  a  name  and  a  type.  The  new  primop  introduces  a  name  with  uninitialized 

object  type  c°.  The  initializer  then  updates  the  type  of  its  named  argument  in  the 

environment.  After  translating  the  previous  example  to  AJVM,  it  is  clear  that  the  drawn 

object  is  initialized: 

let  x  =  new  Pt; 
let  y  =  new  Pt ; 

i nvokespeci  al  Pt.<init>()V  x; 
i nvokevi rtual  Pt.draw()V  x; 

After  i  nvokespeci  al,  the  type  environment  contains  x  >-  Pt  and  y  Pt°. 

Aliases  can  also  occur  in  AJVM  when  the  same  pointer  is  passed  as  two  arguments  to 
a  basic  block.  Translating  the  Java  statement  new  Pt  (f?  x  :  y)  to  JVML  introduces 
a  branch  between  the  new  and  the  i  nvokespeci  al .  A  naive  translation  to  AJVM  might 
introduce  an  alias  because  the  same  pointer  exists  in  two  locations  across  basic  blocks. 
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c  e  {c}  {c\ }  g  {c2 } 

c  <  {c}  {cl}  <  {77} 

T  <  t'  C  <  c'  Vc  G  {c} 

T  []  <T'[]  {C}  <  C7 

Figure  7.7:  Selected  typing  rules 


Our  inference  algorithm  employs  the  same  technique  as  the  Sun  verifier— mark  the 
uninitialized  object  arguments  with  the  offset  of  the  new  instruction.  Then,  we  recognize 
arguments  that  are  aliases  and  coalesce  them. 


7.3.2  Subtyping  and  set  types 


Two  other  interesting  aspects  of  the  AJVM  type  system  are  the  subtype  relation  and  the 
set  types.  The  subtype  relation  (r  r')  handles  numeric  promotions  such  as  I  <  F.  On 
class  and  interface  names  it  mirrors  the  class  hierarchy.  The  rules  for  other  types  are 
in  figure  |7.7|  The  curly  typewriter  braces  {  ■  }  are  the  AJVM  set  types  and  the  Roman 
braces  { ■ }  are  standard  set  notation. 

The  set  elimination  rule  (*)  is  required  when  a  value  of  set  type  is  used  in  a  primop 
with  a  field  or  method  descriptor.  In  function  C  of  figure  |7M|  for  example,  p  is  used  as 
the  self  argument  for  method  draw  in  class  Pt.  The  type  of  p  is  {IntPt,  Col  orPt},  so 
the  type  checker  requires  IntPt  <  Pt  and  ColorPt  <  Pt. 

In  our  example,  we  could  have  used  the  super  class  type  Pt  in  place  of  the  set 
{IntPt,  Col  orPt},  but  with  interfaces  and  multiple  inheritance,  this  is  not  always  pos¬ 
sible.  Both  |Goldberg  (1998)  and  Qian  (19991  have  observed  this  problem;  the  example 
in  figure  [778]  on  the  next  page  is  from  Knobloclc  and  Rehof  (20001.  What  is  the  type  of  x 
after  the  join?  The  only  common  super  type  of  A  and  B  is  Object.  But  then  the  method 
invocations  would  not  be  correct.  We  must  assign  to  x  the  set  type  {A,  B}.  For  the  first 
method  invocation,  the  type  checker  requires  that  {A,  B}  <  SA.  For  the  second  invo- 


106 


CHAPTER  7.  FUNCTIONAL  JAVA  BYTECODE 


interface  SA  {  void  saMeth();  } 
interface  SB  {  void  sbMeth();  } 
interface  A  extends  SA,  SB 
interface  B  extends  SA,  SB 


public  static  void  (boolean  f,  A  a,  B  b)  { 
if  (f)  {  x  =  a;  } 
el  se  {  x  =  b ;  } 
x.  saMethO  ; 
x.  sbMethQ  ; 


Figure  7.8:  The  need  for  set  types 


cation,  {A,  B}  <  SB.  These  subtyping  judgments  are  easily  derived  from  the  interface 
hierarchy  (A  <  SA,  B  <  SA,  A  <  SB,  and  B  <  SB)  using  the  set  elimination  rule  (*). 

We  utilize  subtypes  either  by  subsumption  (if  v  has  type  r  and  r  <  t'  then  v  also 
has  type  t')  or  as  explicit  coercions  (let  x  =  convert[r, r']  v;  ...  where  r  <  t'). 
Our  type  checker  accepts  the  former  but  can  automatically  insert  explicit  coercions  as 
needed. 


7.4  Implementation 

We  have  implemented  the  translation  from  Java  class  files  to  AJVM.  After  parsing  the 
class  file  into  a  more  abstract  form,  methods  are  split  into  basic  blocks.  Next,  type 
inference  determines  the  argument  types  for  each  basic  block.  It  determines  subroutine 
calling  conventions  and  eliminates  aliased  arguments.  Finally,  the  translation  phase 
uses  the  results  of  type  inference  to  guide  conversion  to  AJVM.  Our  type  checker  verifies 
that  the  translation  produced  something  sensible  and  checks  those  JVM  constraints  that 
were  not  already  handled  during  parsing  and  inference.  AJVM  is  a  significant  component 
of  our  prototype;  some  measurements  are  given  in  the  next  chapter. 

Because  our  application  does  not  require  it,  we  have  not  implemented  serialization 
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for  AJVM  programs.  We  could  borrow  the  byte  codes  from  JVML  for  primops,  and  then 
use  relative  instruction  offsets  for  representing  1  et-bound  names.  Or  we  could  follow 
Amme  et  al.  (2001},  who  describe  two  innovative  encoding  techniques— referential  in¬ 
tegrity  and  type  separation— in  which  only  well-formed  programs  can  be  specified.  That 
is,  programs  are  well-formed  by  virtue  of  their  encoding. 


7.5  Related  work 


Katsumata  and  Ohori  (20011  translate  a  subset  of  JVML  into  a  A-calculus  by  regarding 
programs  as  proofs  in  different  systems  of  propositional  logic.  JVML  programs  corre¬ 
spond  to  proofs  of  the  sequent  calculus;  A-programs  correspond  to  natural  deductions. 
Translations  between  these  systems  yield  translations  of  the  underlying  programs.  This 
is  a  very  elegant  approach— translated  programs  are  type-correct  by  construction.  Un¬ 
fortunately,  it  seems  impossible  to  extend  it  to  include  JVML  subroutines  and  excep¬ 
tions. 

Gagnon,  Hendren,  and  Marceau  (20001  give  an  algorithm  to  infer  static  types  for 


local  variables  in  JVML.  Since  they  do  not  use  a  single-assignment  form,  they  must 
occasionally  split  variables  into  their  separate  uses.  Since  they  do  not  support  set  types, 
they  insert  explicit  type  casts  to  solve  the  multiple  interface  problem  described  above. 
Amme  et  al.  (2001)  translate  Java  to  SafeTSA,  an  alternative  mobile  code  represen¬ 


tation  based  on  SSA  form.  Since  they  start  with  Java,  they  avoid  the  complications  of 
subroutines  as  well  as  the  multiple  interface  problem.  Basic  blocks  must  be  split  wher¬ 
ever  exceptions  can  occur,  and  control-flow  edges  are  added  to  the  catch  and  f  i  nal  1  y 
blocks.  Otherwise,  SafeTSA  is  similar  in  spirit  to  AJVM. 


Chapter  8 


A  Prototype  Compiler  for  Java  and  ML 


Previous  chapters  of  this  dissertation  defined  a  flexible  typed  intermediate  language, 
proposed  efficient  implementations  of  many  Java  features  within  that  language,  and 
described  a  high-level  representation  of  Java  bytecode.  To  demonstrate  these  ideas  with 
real  programs,  we  synthesized  all  of  them  within  a  prototype  compiler.  It  compiles  both 
Java  and  ML  programs  using  the  same  back  end  support  and  runtime  system. 


8.1  Design 


We  started  with  version  110.30  of  the  Standard  ML  of  New  Jersey  compiler  (Appel  and 


Mac  Queen  1991]>,  featuring  the  FLINT  typed  intermediate  language  (Shao  1997|  [Shao, 
League,  and  Monnier  1998).  Our  first  step  was  to  develop  and  export  support  modules 
within  the  compiler  that  enable  regular  SML  programs  to  build,  compile,  and  link  FLINT 
code  directly.  Previously,  the  FLINT  functionality  was  available  only  as  an  integrated 
part  of  the  SML  compiler. 

Figure  [8T[on  the  following  page  gives  the  signature  of  a  support  module  that  queries 
the  SML/NJ  static  environment  and  provides  representations  of  ML  types,  constructors, 
and  values  that  can  be  linked  into  a  new  FLINT  program  before  it  is  compiled.  For 
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signature  IMPORTS  =  sig 
type  imports 
val  empty  :  imports 
val  importVal  :  imports  x  string 

—  imports  x  FLINT.  Ivar  x  FLINT,  ty 
val  importTyc  :  string  —  Access .  consig  x  FLINT,  ty 
val  importCon  :  string  —  FLINT. dcon 
val  close  :  imports  x  JFlint  .exp  —  JFlint  .prog 
exception  Unbound  of  string 
end 


Figure  8.1:  Importing  FLINT  code  from  the  SML/NJ  static  environment 


example,  to  use  the  input/output  library  of  ML  from  FLINT  code,  one  will  need  the  type 
of  a  text  output  stream: 


Imports. importTyc  "TextIO.outstream" 


The  imports  type  tracks  all  the  values  that  are  imported  while  building  a  piece  of  FLINT 
code,  so  that  the  close  function  can  link  them  into  create  a  closed  program,  ready  to 
pass  to  the  type  checker  or  back  end. 

We  added  row  kinds  and  existential  types  to  FLINT  and  called  this  extension  JFlint— 
figure  |8.2|  on  the  next  page  contains  part  of  its  signature.  Compared  to  the  abstract 
syntax  of  figure  [47T|  the  implemented  version  is  in  A-normal  form.  Expressions  ending 
with  id  x  exp  bind  their  result  to  identifier  id  in  the  scope  of  exp.  We  updated  the  type 
checker  and  optimization  phases  to  recognize  the  new  features  in  JFlint,  but  left  the 
code  generator  and  runtime  system  unchanged. 

Finally,  we  implemented  the  Java  front  end  as  a  regular  SML  program.  It  parses  Java 
class  files,  analyzes  their  methods,  and  translates  them  to  AJVM.  At  this  stage,  we  could 
perform  class  hierarchy  analysis  or  other  object-aware  optimizations  (Dean,  Grove,  and 
Chambers  1995|[Deanet  al.  1996)  because  the  classes  and  method  calls  are  still  explicit. 


From  the  constant  pool,  the  front  end  determines  what  other  classes  must  be  loaded. 
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signature  JFLINT  =  sig 
datatype  value 

=  Var  of  id  |  Int  of  I nt3 2  .  int  |  String 


(*  identifiers  and  constants  *) 


datatype  exp 


Letrec 

of 

fundee  list  x  exp 

Let 

of 

id  x  exp  x  exp 

Switch 

of 

value  x  ( id  x  exp) 

list 

Call 

of 

id  x  value  list 

Return 

of 

value 

Primop 

of 

primop  x  value  list 

X 

id 

Record 

of 

value  list 

X 

id 

Load 

of 

value  x  int 

X 

id 

Store 

of 

value  x  int  x  value 

x  exp 
x  exp 
x  exp 
x  exp 


Inst 

of 

id 

x  ty 

list 

Fold 

of 

val 

ue  x 

ty 

Unfold 

of 

val 

ue 

Pack 

of 

ty 

list 

x  (value 

x  ty ) 

Open 

of 

val 

ue  x 

id  list 

x  (id 

(*  type  manipulation  instructions  *) 
x  id  x  exp 

x  id  x  exp 

x  id  x  exp 

list  x  id  x  exp 

ty )  list  x  exp 


withtype  fundee  =  id  x  (id  x  ty )  list  x  exp 

end 


Figure  8.2:  Signature  for  JFlint  code 


It  recursively  parses  and  analyzes  the  requisite  classes,  then  computes  the  strongly- 
connected  components  of  the  dependence  graph.  Finally,  each  mutually-dependent 
cluster  of  classes  is  translated  separately  to  JFlint. 

Intuitively,  there  are  two  stages  to  this  translation.  First,  we  analyze  the  class  dec¬ 
laration  to  determine  the  layout  of  the  fields  and  methods,  and  to  generate  representa¬ 
tions  of  the  object  and  class  types.  Figure [83lon  the  following  page  contains  a  fragment 
of  ML  code  for  this  stage.  Although  not  all  the  constructors  are  defined,  its  resemblance 
to  the  object  type  macros  in  figure  [5 (page  [60)  should  be  clear. 

The  next  stage  does  case  analysis  on  the  AJVM  code  and  builds  the  corresponding 
lower-level  JFlint  representation.  Figure  [8~4]  on  the  next  page  contains  a  code  fragment 
for  this  stage.  It  shows  two  helper  functions  that  build  an  unfold  and  open  term, 
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val  objRcd  =  T.lam  ([T.ktyp,  T.  ksubm  nm,  T.ksubf  nf ,  T.ktyp], 
T.rcd  (T. row  (T. red  (T.app  (T.  proj  (  alllnst  ,0), 

[T.var  (1,3)])), 

T.  proj  (  alllnst  ,  1 )))) 

val  selfFn  =  T.lam  ([  T.  ktyp  ,  T. ksubm  nm,  T.ksubf  nf  ], 

T.  fix  (T.ktyp,  T.app  (objRcd, 

[T.var  (2,0),  T.var  (2,1),  T.var  (2,2),  T.var  (1,0)]))) 


val  objTy  =  T.  fix  (T.ktyp, 

T.  exist  ([  T. ksubm  nm,  T.ksubf  nf  ], 

[T.app  (selfFn  ,  [T.var  (2,0),  T.var  (1,0),  T.var  (1,1)])])) 


val  selfTy  =  T.app  (  selfFn  ,[  objTy ,  T. var  (1 ,0),  T.var  (1,1)]) 

Figure  8.3:  Constructing  representations  of  object  types 


(*  generate  unfold  and  open  terms,  in  continuation  passing  style:  0 
fun  unfold  ( tyc  ,  v  ,  k)  = 
let  val  x  =  T.mkLvarO 

in  F.  Unfold  ( v  ,  tyc  ,  T.  id  ,  x  ,  k  (  F.  Var  x )) 

end 

fun  unpack  (ks  ,  tyc  ,  v  ,  k)  = 
let  val  x  =  T.mkLvarO 

fun  f  k  =  (T.mkLvar  (),  k) 
in  F .  Open  (v  ,  map  f  ks  ,  [(  x  ,  tyc  )],  k  (  F .  Var  x )) 

end 

(*  from  case  analysis  on  lambda  JVM  terms:  *) 

|  INVK  (m,  VIRTUAL,  vO  ,  vs)  => 
let  val  (im,  acc  )  =  memberAccess  (im,  m) 

val  {objTy,  selfTy  ,  nm,  nf  ,...}=  classInfoM  m 
in  compileValue  (env,  vO ,  fn  vO  => 
valueOf  (objTy,  vO ,  fn  vO  => 
unfold  (objTy,  vO ,  fn  vO  => 

unpack  ([  T.  ksubm  nm,  T.ksubf  nf  ],  selfTy,  vO  ,  fn  vO  => 
unfold  (  selfTy  ,  vO ,  fn  vl  => 
select  ( SOME  vl,  acc,  fn  vm  => 
compileValues  (env,  vs,  fn  vs  => 

F .  Let  ([ y  ],  F.  Call  (vm,v0::vs), 
nextExp  ))))))))) 

end 


Figure  8.4:  Compiling  invokevirtual 
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Standard  ML  of  New  Jersey  vll0.30  [JFLINT  1.2] 

-  Java. classPath  :=  ["/home/1 eague/r/ java/tests"] ; 
val  it  =  ()  :  unit 

-  val  main  =  Java. run  "Hello"; 

[parsing  Hello] 

[parsing  java/lang/Object] 

[compiling  java/lang/Object] 

[compiling  Hello] 

[i ni ti al i zi ng  java/1 ang/Object] 

[initializing  Hello] 

val  main  =  fn  :  string  list  ->  unit 

-  main  ["Duke"]; 

Hello,  Duke 

val  it  =  ()  :  unit 

-  main  [] ; 

uncaught  exception  ArraylndexOutOfBounds 

raised  at:  Hel 1 o . mai n( [L java/1 ang/Stri ng ; )V 

-  ~D 


Figure  8.5:  Compiling  and  running  a  Java  program  in  SML/NJ 

class  Hello  { 

public  static  void  main(  String  []  args  )  { 

System. out.  println  ("Hello  +  args  [0]); 

} 

} 


Figure  8.6:  A  trivial  Java  program 


respectively.  They  each  have  a  continuation  argument  to  receive  the  new  value  and 
continue  generating  code.  Again,  some  functions  are  omitted,  but  the  resemblance  to 
the  formal  method  call  translation  (figure  |5.7|  rule  |5.14[  page  [63)  should  be  clear. 

On  the  generated  JFlint  code,  we  run  several  contraction  optimizations  (inlining, 
common  subexpression  elimination,  and  so  on),  and  type-check  the  code  after  each 
pass.  We  discard  the  type  information  before  converting  to  MLRISC  (George  1997)  for 
final  instruction  selection  and  register  allocation.  To  generate  typed  machine  code,  we 


would  need  to  preserve  types  throughout  the  back  end.  The  techniques  of  Morrisett 
et  al.  (1999b)  would  apply  directly,  since  JFlint  is  based  on  System  F. 
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Figure|875]on  the  preceding  page  shows  the  SML/JFlint  system  in  action.  The  s  1  anted 
text  represents  user  input.  The  top-level  loop  accepts  Standard  ML  code,  as  usual.  The 
JFlint  front  end  is  controlled  via  the  lava  structure;  its  members  include: 

•  lava.  classPath  :  string  list  ref  Initialized  from  the  CLASSPATH  variable, 
this  is  a  list  of  directories  where  the  loader  will  look  for  class  files. 

•  lava,  load  :  string  ->  unit  looks  up  the  named  class  using  cl  ass  Path,  re¬ 
solves  and  loads  any  dependencies,  then  compiles  the  byte  codes  and  executes 
the  class  initializer. 


•  lava,  run  :  string  ->  string  list  ->  unit  ensures  that  the  named  class 
is  loaded,  then  attempts  to  call  its  mai  n  method  with  the  given  arguments. 


lava,  flush  :  unit  ->  unit  forces  the  Java  subsystem  to  forget  all  previously 
loaded  classes.  Normally,  loaded  classes  persist  across  calls  to  1  oad  and  run;  after 
f  1  ush,  they  must  be  loaded  and  initialized  again. 


The  session  in  figure  [875]  sets  the  classPath,  then  loads  the  Hello  class,  and  binds  its 
mai  n  method,  using  partial  application  of  lava .  run.  The  method  is  then  invoked  twice 
with  different  arguments.  The  second  invocation  erroneously  accesses  argv[0];  this 
error  surfaces  as  the  ML  exception  lava. ArraylndexOutOfBounds.  The  source  code 
for  the  Hel  lo  class  is  in  figure  [876]  on  the  page  before. 

In  this  prototype,  SML  code  interacts  only  with  a  complete  Java  program.  Since 
both  run  in  the  same  runtime  system,  very  fine-grained  interactions  are  possible,  but 
have  not  been  our  focus.  Benton  and  Kennedy  (19991  designed  extensions  to  SML  to 
allow  seamless  interaction  with  Java  code  when  both  are  compiled  for  the  Java  virtual 
machine.  Their  design  should  work  quite  well  in  our  setting  also— and  since  JFlint  is 
more  expressive  than  JVML,  we  do  not  need  to  monomorphize  functors  and  polymorphic 


functions. 
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This  is  essentially  a  static  Java  compiler,  as  it  does  not  handle  dynamic  class  loading 
or  the  j  ava .  1  ang  .  ref  1  ect  API.  These  features  are  more  difficult  to  verify  using  a  static 
type  system,  but  they  are  topics  of  ongoing  research.  The  SML  runtime  system  does  not 
yet  support  kernel  threads,  so  we  have  also  ignored  Java’s  concurrency  features.  Also, 
the  runtime  system  does  not,  for  now,  dynamically  load  native  code.  This  is  a  dubious 
practice  anyway;  such  code  has  free  reign  over  the  runtime  system,  thus  nullifying  any 
safety  guarantees  won  by  verifying  the  pure  Java  code.  Nevertheless,  this  restriction  is 
unfortunate  because  it  limits  the  set  of  existing  Java  libraries  that  we  can  use. 


8.2  Synergy 


One  of  the  benefits  of  our  design  is  the  synergy  between  the  encodings  of  Java  and  ML. 
JFlint  does  not  have  classes,  methods,  or  modules  as  primitives.  Rather,  the  records  in 
JFlint  model  Java  objects,  vtables,  classes  and  interfaces,  plus  ML  records  and  the  value 
parts  of  ML  modules.  Neither  Java  nor  ML  has  a  universal  quantifier,  but  it  is  useful 
for  encoding  both  Java  inheritance  and  ML’s  parametric  polymorphism.  The  existential 
type  is  essential  for  object  encoding,  but  also  useful  for  ML  closures  and  abstract  data 
types. 

Contrast  this  with  other  common  typed  intermediate  formats.  JVM  class  files  are 
very  high-level  and  quite  partial  to  the  Java  language.  The  bytecode  language  (JVML) 
includes  no  facilities  for  specifying  data  layouts  or  expressing  many  common  optimiza¬ 
tions.  Compiling  other  languages  for  the  JVM  means  making  foreign  constructs  look 
and  act  like  Java  classes  or  objects.  That  so  many  translations  exist  (|Tolksdorf~|l  is  a 
testament  to  the  utility  of  the  mobile  code  concept,  and  to  the  ubiquity  of  the  JVM  itself. 

To  some  extent,  the  Microsoft  Common  Language  Infrastructure  (CLI)  alleviates 
these  problems  (Microsoft  Corjx,  et  al.  I.  It  supports  user-defined  value  types,  stack 
allocation,  tail  calls,  and  pointer  arithmetic  (which  is  outside  the  verifiable  subset).  CLI 
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has  the  tendency  to  incorporate  the  union  of  all  requested  features.  Its  instructions 
distinguish,  for  example,  between  loading  functions  vs.  values  from  objects  vs.  classes. 
Still,  it  tends  to  prefer  a  single-inheritance  class-based  language.  A  recent  proposal  to 
extend  CLI  for  functional  language  interoperability  (Syme  20011  added  no  fewer  than  6 
new  types  and  12  new  instructions  (bringing  the  total  number  of  cal  1  instructions  to 
5)  and  it  still  does  not  support  ML’s  higher-order  modules  (Harper,  Mitchell,  and  Moggi 
19901  or  Haskell’s  constructor  classes  (Jones  1995). 


We  believe  this  synergy  speaks  well  of  our  approach  in  general.  Still,  it  does  not 
mean  that  we  can  support  all  type-safe  source  languages  equally  well.  Java  and  ML  still 
have  much  in  common;  they  work  well  with  precise  generational  garbage  collection  and 


their  exception  models  are  similar  enough.  Weakly  typed  formats,  such  as  C—  (Peyton 


Jones,  Ramsey  and  Reig  1999;  Ramsey  and  Peyton  Jones  2000),  are  more  ambitious  in 
supporting  a  wider  variety  of  language  features,  including  different  exception  and  mem¬ 
ory  models.  Practical  type  systems  to  support  that  level  of  flexibility  are  challenging, 
but  are  interesting  for  future  work. 


8.3  Implementation 


To  support  efficient  compilation,  types  are  represented  differently  from  code.  Figure|877| 
contains  part  of  the  abstract  interface  to  our  type  system.  Compared  to  the  syntax  of 
figure  phT] on  page  [32]  the  record  labels  are  missing.  We  use  integer  offsets  exclusively. 
Further,  we  use  de  Bruijn  indices  rather  than  named  type  variables. 

If  a  type-preserving  compiler  is  to  scale  well,  extreme  care  must  be  taken  in  imple¬ 
menting  the  type  representations  and  operations.  Several  years  ago,  we  presented  a 
series  of  techniques  which,  taken  together,  made  the  FLINT  typed  IL  practical  enough 
to  use  in  a  production  compiler  (Shao,  League,  and  Monnier  1998).  Different  type  struc¬ 
tures  arise  in  the  Java  encodings,  but  the  techniques  are  as  successful  as  ever. 
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signature  JTYPE  =  sig 
type  ty 

val  var  :  int  x  int  —  ty 
val  prim  :  primtyc  —  ty 
val  arrow  :  ty  list  x  ty  -  ty 
val  record  :  ty  ■—  ty 
val  row  :  ty  x  ty  -  ty 
val  empty  :  int  —  ty 


(*  function  type  *) 
(*  record  types  *) 


(*  type  variable  *) 


(*  quantified  types  *) 


val  forall  :  kind  list  x  ty  list  —  ty 

val  exists  :  kind  list  x  ty  list  —  ty 

val  fixpt  :  kind  list  x  ty  list  —  ty 

val  lam  :  kind  list  x  ty  -  ty 


(*  higher-order  *) 


val  app  :  ty  x  ty  list  —  ty 


end 


Figure  8.7:  Abstract  interface  for  JFlint  type  representation 


We  represent  types  as  directed  acyclic  graphs.  Part  of  what  the  JTYPE  interface  hides 
is  automatic  hashing  to  ensure  maximal  sharing  in  the  graph  representation.  Type 
variables  are  represented  as  pairs  of  integers  which  represent  the  lexical  binding  depth 
and  offset.  This  means  that  types  which  differ  only  in  their  variable  names  share  the 
same  representation.  Therefore,  the  equivalence  of  two  types  in  normal  form  is  simply 
pointer  equivalence. 

A  common  operation  on  types  is  the  substitution  of  types  for  variables.  Replacing 
variables  using  assignment  is  not  an  option  because  so  much  of  the  graph  is  shared. 
We  create  the  instantiated  type  lazily,  memoizing  each  result  so  that  the  next  time  we 
need  the  same  substitution  it  is  available  immediately. 

With  these  techniques,  compile  and  verification  times  remain  reasonable.  A  full  type¬ 
preserving  compile  of  the  12  classes  in  the  CaffeineMark™  3.0  embedded  benchmark 
series  takes  2.4  seconds  on  a  927  MHz  Intel  Pentium  III  Linux  workstation.  This  is  about 
60%  more  than  gcj,  the  GNU  Java  compiler  {Bothner  1 997|.  Since  gcj  is  written  in  C 
and  our  compiler  in  SML,  the  gap  is  easily  attributed  to  linguistic  differences.  Verifying 
both  the  AJVM  and  the  JFlint  code  adds  another  half  second. 
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Run  times  are  promising,  but  can  be  improved.  Our  goal,  of  course,  is  to  preserve 
type  safety;  speed  is  secondary.  CaffeineMark  runs  at  about  a  third  the  speed  in  SML/NJ 
compared  to  gcj  -02.  This  difference  should  not  be  attributed  to  type  preservation; 
we  have  already  shown  that,  with  types  erased,  our  object  layouts  and  operations  are 
just  like  the  standard  untyped  implementations.  The  difference  has  more  to  do  with 
many  other  properties  of  our  compiler.  First,  many  standard  optimizations,  especially 
on  loops,  have  not  been  implemented  in  JFlint  yet.  Second,  the  code  generator  is  still 
heavily  tuned  for  SML;  record  representations,  for  example,  are  more  boxed  than  they 
need  to  be.  Finally,  the  runtime  system  is  also  tuned  for  SML;  to  support  cal  1  cc,  every 
activation  record  is  heap-allocated  and  subject  to  garbage  collection. 


Chapter  9 


Future  Directions 


We  have  shown  that  a  strongly-typed  compiler  intermediate  language  can  safely  and 
efficiently  accommodate  two  very  different  programming  languages.  The  intermediate 
language,  JFlint,  is  sound,  decidable,  and  already  supports  ML.  We  developed  novel, 
efficient  techniques  for  compiling  Java  and  have  shown  that  well-typed  Featherweight 
Java  programs  are  mapped  to  well-typed  Mini  JFlint  programs.  Moreover,  the  encodings 
are  synergetic  with  the  translation  of  ML.  In  this  final  chapter,  we  briefly  survey  a  few 
interesting  avenues  for  future  research. 


9. 1  More  inclusive  encodings 


We  developed  our  techniques  in  the  context  of  Java,  and  they  should  apply  to  sim¬ 
ilar  languages,  such  as  C#  (Liberty  20021.  There  are,  however,  more  experimental 
languages— Moby  (|Fisher  and  Reppy  19991  and  Loom  (Bruce,  Fiech,  and  Petersen  1997(l, 
for  example— with  different  object  models.  They  allow  classes  as  module  parameters, 
treat  them  as  first-class  values,  and  use  different  notions  of  subtyping.  It  is  still  not 
clear  how  to  map  these  features  efficiently  to  a  typed  A-calculus  (Vanderwaart _1999 1. 

Fisher,  Reppy,  and  Riecke  (2000)  proposed  Aink^  (read  “links”),  an  untyped  calculus 
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that  can  express  and  optimize  the  object  models  of  a  variety  of  languages,  including 
Java,  Moby,  Loom,  and  OCaml.  Aink^  reasons  about  slots  to  build  method  suites  either 
at  compile  time  or  link  time.  It  also  features  dictionaries  to  dynamically  map  method 
labels  to  slots.  With  this  flexibility,  designing  a  sound  type  system  for  Aink^  seems  a 
daunting  task. 

Some  recent  work  demonstrates  that  such  reasoning  just  might  be  within  the  purview 
of  a  decidable  type  system.  Shao  et  al.  (20021,  for  example,  reason  about  integers  and 
integer  addition  at  the  type  level  so  that  array  bounds  checks  can  be  optimized  away.  In 
their  system,  records  and  arrays  are  both  defined  using  an  underlying  tuple  construc¬ 
tor,  where  the  length  can  be  known  either  statically  or  dynamically.  Perhaps  the  method 
suites  of  Aink^  could  be  typed  using  similar  ideas. 


9.2  More  substantial  implementations 


Our  prototype  shows  that  the  encodings  we  developed  can  be  implemented  in  a  real 
compiler.  It  is  not,  unfortunately,  substantial  enough  that  it  could  be  used  as  a  drop-in 
replacement  for  a  Java  virtual  machine.  Certainly,  there  is  more  to  be  learned  in  the 
realm  of  efficient  and  effective  implementation  of  type-preserving  compilers. 

We  recently  started  to  collaborate  with  a  group  at  Intel  Labs  on  their  IA64  just-in-time 
compiler  for  the  Microsoft  .NET  platform.  The  Intel  group  already  found  that  limited 
type  information  preserved  in  the  compiler  is  useful  for  optimization  (disambiguating 


memory  references,  for  example)  and  for  accurate  garbage  collection  (Stichnoth,  Lueh,| 
and  Cierniak  1999;  Cierniak^Lueh,  and  Stichnoth  20001.  They  understand  that  a  more 
rigorous  typing  discipline  would  bring  security  benefits,  and  are  curious  about  the  im¬ 
pact  type-preservation  might  have  on  the  performance,  reliability,  and  maintainability 
of  their  system. 

This  project  is  exciting  for  several  reasons.  First,  .NET  is  a  more  ambitious  platform 
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than  Java,  somewhat  less  partial  to  a  single  source  language.  Also,  just-in-time  compi¬ 
lation  imposes  new  requirements,  most  notably  on  the  speed  of  the  compiler.  Finally, 
working  with  researchers  and  developers  in  industry  would  help  bring  pragmatic  con¬ 
cerns  to  the  foreground.  The  project  would  certainly  yield  an  exciting  new  batch  of 
practical  and  theoretical  problems  to  solve. 
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